dans le livre de swinnen l exercice suivant est propos=E9 :
5=2E9. =C9crivez un script qui recopie une cha=EEne (dans une nouvelle
variable) en l'inversant.
Ainsi par exemple, =AB zorglub =BB deviendra =AB bulgroz =BB.
La solution donn=E9e par l'auteur :
#! /usr/bin/env python
# -*- coding: Latin-1 -*-
# Inversion d'une cha=EEne de caract=E8res
# Cha=EEne fournie au d=E9part :
ch =3D raw_input ('entrer un mot: ' )
lc =3D len(ch) # nombre de caract=E8res total
i =3D lc - 1 # le traitement commencera =E0 partir du dernier
caract=E8re
nch =3D "" # nouvelle cha=EEne =E0 construire (vide au d =E9part)
while i >=3D 0:
nch =3D nch + ch[i]
i =3D i - 1
# Affichage :
print nch
ca marche mais je ne comprend pas pourquoi la variable "i" est
encapsul=E9 la valeur "lc - 1" et non pourquoi simplement la valeur "lc
" , j'avais fait un script similaire avant de regarder la solution
mais je n'avais pas diminuer la valeur lc de 1 . Il est =E9crit que
c'est pour commencer par le dernier caract=E8re , mais si l'on enl=E8ve
1 , ne commence t-on pas avec l'avant dernier caract=E8re ?
output erreur sans la valeur lc - 1 :
me@robby:~/python.swinnen/solutions$ python exercice_5_09.py
entrer un mot: hello
Traceback (most recent call last):
File "exercice_5_09.py", line 12, in ?
nch =3D nch + ch[i]
IndexError: string index out of range
quelqu'un peut m'expliquer ? j'ai d=E9j=E0 chercher le nom de l erreur
mais elle pas trop compr=E9hensible a ce niveau ..
Cela sous-entend que commencer à compter à zéro est une notion "actuelle", plus moderne. Mais cela est loin d'être évident. On a pris l'habitude de faire avec, ce qui n'implique pas que ce soit mieux.
Il y aurait là-dessous le fait qu'un registre de processeur s'initialise à zéro que ce ne serait pas étonnant... et pourquoi 0 ? parce que électriquement ça se fait tout seul. Pourquoi pas +1 ? parce qu'il faut un cycle de plus pour initialiser un registre à 1 ? On demande un électronicien dans la salle...
Je pense que, historiquement, le décompte à partir de zéro qui est utilisé en C (et dans de nombreux langages) provient en fait des modes d'adressage relatif des processeurs qui utilisent deux registres : le premier contient l'adresse en mémoire du tableau et le second indique le décalage à appliquer à cette adresse de départ pour accéder à l'élément cherché.
On peut donc voir cela non pas comme un index (un numéro d'ordre) mais plutôt comme un offset (un décalage) par rapport au point de départ.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Cela sous-entend que commencer à compter à zéro est une notion
"actuelle", plus moderne.
Mais cela est loin d'être évident. On a pris l'habitude de faire
avec, ce qui n'implique pas que ce soit mieux.
Il y aurait là-dessous le fait qu'un registre de processeur
s'initialise à zéro que ce ne serait pas étonnant...
et pourquoi 0 ? parce que électriquement ça se fait tout seul.
Pourquoi pas +1 ? parce qu'il faut un cycle de plus pour initialiser
un registre à 1 ? On demande un électronicien dans la salle...
Je pense que, historiquement, le décompte à partir de zéro qui est
utilisé en C (et dans de nombreux langages) provient en fait des modes
d'adressage relatif des processeurs qui utilisent deux registres : le
premier contient l'adresse en mémoire du tableau et le second indique
le décalage à appliquer à cette adresse de départ pour accéder à
l'élément cherché.
On peut donc voir cela non pas comme un index (un numéro d'ordre) mais
plutôt comme un offset (un décalage) par rapport au point de départ.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Cela sous-entend que commencer à compter à zéro est une notion "actuelle", plus moderne. Mais cela est loin d'être évident. On a pris l'habitude de faire avec, ce qui n'implique pas que ce soit mieux.
Il y aurait là-dessous le fait qu'un registre de processeur s'initialise à zéro que ce ne serait pas étonnant... et pourquoi 0 ? parce que électriquement ça se fait tout seul. Pourquoi pas +1 ? parce qu'il faut un cycle de plus pour initialiser un registre à 1 ? On demande un électronicien dans la salle...
Je pense que, historiquement, le décompte à partir de zéro qui est utilisé en C (et dans de nombreux langages) provient en fait des modes d'adressage relatif des processeurs qui utilisent deux registres : le premier contient l'adresse en mémoire du tableau et le second indique le décalage à appliquer à cette adresse de départ pour accéder à l'élément cherché.
On peut donc voir cela non pas comme un index (un numéro d'ordre) mais plutôt comme un offset (un décalage) par rapport au point de départ.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Sébastien Kirche
Le 28 septembre 2007 à 12:53, Laurent Pointal a formulé :
OCaml je ne connais pas mais tout un pan d'Ada est prévu pour du temps réel, du parallélisme avec gestion de rendez-vous, ce genre de chose. Et le compilo est si chatouilleux par rapport aux erreurs de programmation courantes quand lorsqu'un programme Ada compile, on n'est pas loin d'un programme qui fonctionne.
Ariane 5 ? Qui a dit Ariane 5 ?-)
C'était pas un problème plus 'hard' (bus qui saturait et réinitialisait le système, celui-ci considérant au démarrage qu'il était au niveau du sol)?
Donc pas trop lié au langage...
Le problème d'Ariane 5 c'est qu'il ont réutilisé des modules soft de la génération précédente sans se poser trop de questions (pour des problèmes de coût il me semble) quand aux différences. Après tout si ça marchait pour la série 4 ça devait pouvoir marcher pour la série suivante. Sauf que le nouveau modèle poussait plus fort, plus vite et des charges plus importantes. Le calculateur s'est retrouvé en dehors des plages de fonctionnement prévues et croyant voir l'engin partir dans le décor, il a activé l'autodestruction. En décortiquant, ils se sont rendu compte que des débordement de capacité auraient pu être gérés par le programme, mais pour gagner en performance ça avait été compilé en désactivant les vérifications fournies par le compilo.
Du coup ce qui a été économisé avant a été largement perdu dans l'accident. Un peu comme avec Hubble : on a économisé la vérification du miroir avant lancement mais ça a coûté une mission spatiale pour aller poser des lunettes sur le nez du télescope myope... :oP -- Sébastien Kirche
Le 28 septembre 2007 à 12:53, Laurent Pointal a formulé :
OCaml je ne connais pas mais tout un pan d'Ada est prévu pour du
temps réel, du parallélisme avec gestion de rendez-vous, ce genre
de chose. Et le compilo est si chatouilleux par rapport aux
erreurs de programmation courantes quand lorsqu'un programme Ada
compile, on n'est pas loin d'un programme qui fonctionne.
Ariane 5 ? Qui a dit Ariane 5 ?-)
C'était pas un problème plus 'hard' (bus qui saturait et
réinitialisait le système, celui-ci considérant au démarrage qu'il
était au niveau du sol)?
Donc pas trop lié au langage...
Le problème d'Ariane 5 c'est qu'il ont réutilisé des modules soft de la
génération précédente sans se poser trop de questions (pour des
problèmes de coût il me semble) quand aux différences. Après tout si ça
marchait pour la série 4 ça devait pouvoir marcher pour la série
suivante. Sauf que le nouveau modèle poussait plus fort, plus vite et
des charges plus importantes. Le calculateur s'est retrouvé en dehors
des plages de fonctionnement prévues et croyant voir l'engin partir dans
le décor, il a activé l'autodestruction. En décortiquant, ils se sont
rendu compte que des débordement de capacité auraient pu être gérés par
le programme, mais pour gagner en performance ça avait été compilé en
désactivant les vérifications fournies par le compilo.
Du coup ce qui a été économisé avant a été largement perdu dans
l'accident. Un peu comme avec Hubble : on a économisé la vérification du
miroir avant lancement mais ça a coûté une mission spatiale pour aller
poser des lunettes sur le nez du télescope myope... :oP
--
Sébastien Kirche
Le 28 septembre 2007 à 12:53, Laurent Pointal a formulé :
OCaml je ne connais pas mais tout un pan d'Ada est prévu pour du temps réel, du parallélisme avec gestion de rendez-vous, ce genre de chose. Et le compilo est si chatouilleux par rapport aux erreurs de programmation courantes quand lorsqu'un programme Ada compile, on n'est pas loin d'un programme qui fonctionne.
Ariane 5 ? Qui a dit Ariane 5 ?-)
C'était pas un problème plus 'hard' (bus qui saturait et réinitialisait le système, celui-ci considérant au démarrage qu'il était au niveau du sol)?
Donc pas trop lié au langage...
Le problème d'Ariane 5 c'est qu'il ont réutilisé des modules soft de la génération précédente sans se poser trop de questions (pour des problèmes de coût il me semble) quand aux différences. Après tout si ça marchait pour la série 4 ça devait pouvoir marcher pour la série suivante. Sauf que le nouveau modèle poussait plus fort, plus vite et des charges plus importantes. Le calculateur s'est retrouvé en dehors des plages de fonctionnement prévues et croyant voir l'engin partir dans le décor, il a activé l'autodestruction. En décortiquant, ils se sont rendu compte que des débordement de capacité auraient pu être gérés par le programme, mais pour gagner en performance ça avait été compilé en désactivant les vérifications fournies par le compilo.
Du coup ce qui a été économisé avant a été largement perdu dans l'accident. Un peu comme avec Hubble : on a économisé la vérification du miroir avant lancement mais ça a coûté une mission spatiale pour aller poser des lunettes sur le nez du télescope myope... :oP -- Sébastien Kirche
Sébastien Kirche
Le 28 septembre 2007 à 16:50, Bruno Desthuilliers vraute :
En d'autres termes, même avec ADA, le fait de passer la compile ne garantie pas grand chose. CQFD.
Ce que je voulais dire c'est que qu'un compilo C par exemple est beaucoup plus laxiste qu'un compilo Ada. Un débutant peut facilement se faire avoir par des plaisanteries du style « if (variable = valeur) » qui donne un test qui marche à tous les coups (puisque c'est en fait une affectation, le test étant ==) alors que le compilo ada te le signalera.
Il y a d'autres choses que l'ada ne te permet pas comme comparer des caractères avec des entiers puisque ce ce sont des types différents, alors que j'ai souvent volontairement manipulé des caractères avec des entiers pour comparer ou faire des traitements (forcer des minuscules ou majuscules, ...).
Bien sûr ce n'est pas la panacée et ça ne remplace pas le cerveau du développeur mais ça oblige à être rigoureux, alors que le C permet d'être fainéant. Des fois c'est bien, mais pas toujours. Un programme C qui compile, on sait juste qu'il n'y a pas d'erreur de syntaxe.
C'est en cela que je disais qu'un programme Ada « qui compile » se rapproche d'un programme qui fonctionne, et je le maintiens :) -- Sébastien Kirche
Le 28 septembre 2007 à 16:50, Bruno Desthuilliers vraute :
En d'autres termes, même avec ADA, le fait de passer la compile ne
garantie pas grand chose. CQFD.
Ce que je voulais dire c'est que qu'un compilo C par exemple est
beaucoup plus laxiste qu'un compilo Ada. Un débutant peut facilement se
faire avoir par des plaisanteries du style « if (variable = valeur) »
qui donne un test qui marche à tous les coups (puisque c'est en fait une
affectation, le test étant ==) alors que le compilo ada te le signalera.
Il y a d'autres choses que l'ada ne te permet pas comme comparer des
caractères avec des entiers puisque ce ce sont des types différents,
alors que j'ai souvent volontairement manipulé des caractères avec des
entiers pour comparer ou faire des traitements (forcer des minuscules
ou majuscules, ...).
Bien sûr ce n'est pas la panacée et ça ne remplace pas le cerveau du
développeur mais ça oblige à être rigoureux, alors que le C permet
d'être fainéant. Des fois c'est bien, mais pas toujours. Un programme C
qui compile, on sait juste qu'il n'y a pas d'erreur de syntaxe.
C'est en cela que je disais qu'un programme Ada « qui compile » se
rapproche d'un programme qui fonctionne, et je le maintiens :)
--
Sébastien Kirche
Le 28 septembre 2007 à 16:50, Bruno Desthuilliers vraute :
En d'autres termes, même avec ADA, le fait de passer la compile ne garantie pas grand chose. CQFD.
Ce que je voulais dire c'est que qu'un compilo C par exemple est beaucoup plus laxiste qu'un compilo Ada. Un débutant peut facilement se faire avoir par des plaisanteries du style « if (variable = valeur) » qui donne un test qui marche à tous les coups (puisque c'est en fait une affectation, le test étant ==) alors que le compilo ada te le signalera.
Il y a d'autres choses que l'ada ne te permet pas comme comparer des caractères avec des entiers puisque ce ce sont des types différents, alors que j'ai souvent volontairement manipulé des caractères avec des entiers pour comparer ou faire des traitements (forcer des minuscules ou majuscules, ...).
Bien sûr ce n'est pas la panacée et ça ne remplace pas le cerveau du développeur mais ça oblige à être rigoureux, alors que le C permet d'être fainéant. Des fois c'est bien, mais pas toujours. Un programme C qui compile, on sait juste qu'il n'y a pas d'erreur de syntaxe.
C'est en cela que je disais qu'un programme Ada « qui compile » se rapproche d'un programme qui fonctionne, et je le maintiens :) -- Sébastien Kirche
BertrandB
Méta-MCI (MVP) wrote:
Mais, bon, on ne va pas changer Python pour ça...
Ah, mais non! Il y a bien Stackless qui est un "fork" de Python, tu pourrais faire French, qui serait un fork-a-mots-cles-Fr de Python...
Bon je sors... Il y eut dans le temps des Basic francisé et c'est encore en grande
partie le cas pour pour excel
Sinon Stackless n'est pas vraiment un fork/hack de python mais de CPython. Au niveau langage c'est python.
Méta-MCI (MVP) wrote:
Mais, bon, on ne va pas changer Python pour ça...
Ah, mais non! Il y a bien Stackless qui est un "fork" de Python, tu
pourrais faire French, qui serait un fork-a-mots-cles-Fr de Python...
Bon je sors...
Il y eut dans le temps des Basic francisé et c'est encore en grande
partie le cas pour pour excel
Sinon Stackless n'est pas vraiment un fork/hack de python mais de
CPython. Au niveau langage c'est python.
Ah, mais non! Il y a bien Stackless qui est un "fork" de Python, tu pourrais faire French, qui serait un fork-a-mots-cles-Fr de Python...
Bon je sors... Il y eut dans le temps des Basic francisé et c'est encore en grande
partie le cas pour pour excel
Sinon Stackless n'est pas vraiment un fork/hack de python mais de CPython. Au niveau langage c'est python.
Pierre Maurette
Le 28 septembre 2007 à 16:50, Bruno Desthuilliers vraute :
En d'autres termes, même avec ADA, le fait de passer la compile ne garantie pas grand chose. CQFD.
Ce que je voulais dire c'est que qu'un compilo C par exemple est beaucoup plus laxiste qu'un compilo Ada. Un débutant peut facilement se faire avoir par des plaisanteries du style « if (variable = valeur) » qui donne un test qui marche à tous les coups (puisque c'est en fait une affectation, le test étant ==) alors que le compilo ada te le signalera.
Attention, c'est plein de bourdes, votre démo. D'abord, le test if (variable = valeur) "marchera" si et seulement si /valeur/ a une valeur différente de 0. Ensuite, à un niveau de warning même pas paranoïaque, tous les compilateurs que je pratique signalent ici la possibilité d'une faute de frappe. Certains sont polis, et préconisent de parenthéser: "warning: suggest parentheses around assignment used as truth value" Donc n'importe quel programmeur soit sera alerté de son erreur (= à la place de ==), soit aura codé: if((variable = valeur) != 0) Un compilateur C n'est pas un outil de production en lui-même. Il n'est rien sans un paramétrage imposé, des règles de style et éventuellement quelques outils de validation. Enfin, la solution évidente au problème que vous rapportez est d'éviter de permettre à un "débutant absolu" de programmer les modules RT de gestion d'un lanceur spatial.
-- Pierre Maurette
Le 28 septembre 2007 à 16:50, Bruno Desthuilliers vraute :
En d'autres termes, même avec ADA, le fait de passer la compile ne
garantie pas grand chose. CQFD.
Ce que je voulais dire c'est que qu'un compilo C par exemple est
beaucoup plus laxiste qu'un compilo Ada. Un débutant peut facilement se
faire avoir par des plaisanteries du style « if (variable = valeur) »
qui donne un test qui marche à tous les coups (puisque c'est en fait une
affectation, le test étant ==) alors que le compilo ada te le signalera.
Attention, c'est plein de bourdes, votre démo. D'abord, le test
if (variable = valeur)
"marchera" si et seulement si /valeur/ a une valeur différente de 0.
Ensuite, à un niveau de warning même pas paranoïaque, tous les
compilateurs que je pratique signalent ici la possibilité d'une faute
de frappe. Certains sont polis, et préconisent de parenthéser:
"warning: suggest parentheses around assignment used as truth value"
Donc n'importe quel programmeur soit sera alerté de son erreur (= à la
place de ==), soit aura codé:
if((variable = valeur) != 0)
Un compilateur C n'est pas un outil de production en lui-même. Il n'est
rien sans un paramétrage imposé, des règles de style et éventuellement
quelques outils de validation.
Enfin, la solution évidente au problème que vous rapportez est d'éviter
de permettre à un "débutant absolu" de programmer les modules RT de
gestion d'un lanceur spatial.
Le 28 septembre 2007 à 16:50, Bruno Desthuilliers vraute :
En d'autres termes, même avec ADA, le fait de passer la compile ne garantie pas grand chose. CQFD.
Ce que je voulais dire c'est que qu'un compilo C par exemple est beaucoup plus laxiste qu'un compilo Ada. Un débutant peut facilement se faire avoir par des plaisanteries du style « if (variable = valeur) » qui donne un test qui marche à tous les coups (puisque c'est en fait une affectation, le test étant ==) alors que le compilo ada te le signalera.
Attention, c'est plein de bourdes, votre démo. D'abord, le test if (variable = valeur) "marchera" si et seulement si /valeur/ a une valeur différente de 0. Ensuite, à un niveau de warning même pas paranoïaque, tous les compilateurs que je pratique signalent ici la possibilité d'une faute de frappe. Certains sont polis, et préconisent de parenthéser: "warning: suggest parentheses around assignment used as truth value" Donc n'importe quel programmeur soit sera alerté de son erreur (= à la place de ==), soit aura codé: if((variable = valeur) != 0) Un compilateur C n'est pas un outil de production en lui-même. Il n'est rien sans un paramétrage imposé, des règles de style et éventuellement quelques outils de validation. Enfin, la solution évidente au problème que vous rapportez est d'éviter de permettre à un "débutant absolu" de programmer les modules RT de gestion d'un lanceur spatial.
-- Pierre Maurette
MC
Salut !
0 or 1? My compromise of 0.5
;o) ça pourrait déboucher sur un nouveau concept de langage...
-- @-salutations
Michel Claveau
Salut !
0 or 1? My compromise of 0.5
;o) ça pourrait déboucher sur un nouveau concept de langage...
Et l'assembleur ? Sinon, il y a aussi brainfuck...
-- @-salutations
Michel Claveau
NicolasP
Je ne saurais trop que dire ; C est universellement utilisé, mais franchement pas pratique, en tout cas pour l'usage que j'ai d'un langage de programmation. Perso, je programme tout en C. Et je ne peux pas faire autrement.
Sur une machine où il y a 32Ko de RAM et 256Ko de FLASH pour le programme, un interpréteur Python aurait du mal a rentrer. Et sur d'autres machines sur lesquelles il y a plus de ressources, c'est du temps réel dur qu'il me faut. Hormis le C, point de salut.
Juste par curiosité: des langages comme ADA ou OCaml ne se prêtent pas à l'exercice ?
Je ne connais pas ces langages. Comme il a été dit précédemment, le C
est le langage le plus "universel". Même si ce n'est pas toujours le plus adapté, on peut tout faire avec.
Je n'en disconviens pas - mais cela justifie-t-il ton "Hormis le C, point de salut" ?
Effectivement, il y l'assembleur qui est l'arme absolue. Utilisable dans toutes les situations possibles, sur n'importe quel matériel. Bon, coté portabilité, c'est pas ça. Et puis, pour programmer plus que quelques lignes, il faut être bien accroché.
Ce que je veux dire, c'est que on trouve toujours (ou presque) un compilateur C pour un micro donné. Ce qui n'est pas le cas les autres langages. Et le C est tellement bas niveau (on pourrait presque dire que c'est une surcouche de l'assembleur) que l'on peut générer du code pour tous les besoins. J'ai un système qui tourne avec 8Ko de ROM et 256 octets de RAM. A part l'assembleur et le C, je ne connais pas de langage adapté. Et surtout, je ne connais pas d'autre langage qui possède un compilateur conçu pour mon micro. Attention, je n'ai pas dit que le C est le langage idéal ou le plus universel ou quoi que ce soit d'autre. Je dis qu'on trouve toujours un compilateur C à se mettre sous la main. Et dans certains cas particuliers, genre temps réel dur, en C tout est sous contrôle. Avec d'autres langages (y compris C++), on ne maitrise pas tout.
Nicolas
Je ne saurais trop que dire ; C est universellement utilisé, mais
franchement pas pratique, en tout cas pour l'usage que j'ai d'un
langage de programmation.
Perso, je programme tout en C. Et je ne peux pas faire autrement.
Sur une machine où il y a 32Ko de RAM et 256Ko de FLASH pour le
programme, un interpréteur Python aurait du mal a rentrer.
Et sur d'autres machines sur lesquelles il y a plus de ressources,
c'est du temps réel dur qu'il me faut. Hormis le C, point de salut.
Juste par curiosité: des langages comme ADA ou OCaml ne se prêtent
pas à l'exercice ?
Je ne connais pas ces langages. Comme il a été dit précédemment, le C
est le langage le plus "universel". Même si ce n'est pas toujours le
plus adapté, on peut tout faire avec.
Je n'en disconviens pas - mais cela justifie-t-il ton "Hormis le C,
point de salut" ?
Effectivement, il y l'assembleur qui est l'arme absolue. Utilisable dans toutes les situations possibles, sur n'importe quel matériel. Bon, coté portabilité, c'est pas ça. Et puis, pour programmer plus que quelques lignes, il faut être bien accroché.
Ce que je veux dire, c'est que on trouve toujours (ou presque) un compilateur C pour un micro donné. Ce qui n'est pas le cas les autres langages.
Et le C est tellement bas niveau (on pourrait presque dire que c'est une surcouche de l'assembleur) que l'on peut générer du code pour tous les besoins. J'ai un système qui tourne avec 8Ko de ROM et 256 octets de RAM. A part l'assembleur et le C, je ne connais pas de langage adapté. Et surtout, je ne connais pas d'autre langage qui possède un compilateur conçu pour mon micro.
Attention, je n'ai pas dit que le C est le langage idéal ou le plus universel ou quoi que ce soit d'autre. Je dis qu'on trouve toujours un compilateur C à se mettre sous la main.
Et dans certains cas particuliers, genre temps réel dur, en C tout est sous contrôle. Avec d'autres langages (y compris C++), on ne maitrise pas tout.
Je ne saurais trop que dire ; C est universellement utilisé, mais franchement pas pratique, en tout cas pour l'usage que j'ai d'un langage de programmation. Perso, je programme tout en C. Et je ne peux pas faire autrement.
Sur une machine où il y a 32Ko de RAM et 256Ko de FLASH pour le programme, un interpréteur Python aurait du mal a rentrer. Et sur d'autres machines sur lesquelles il y a plus de ressources, c'est du temps réel dur qu'il me faut. Hormis le C, point de salut.
Juste par curiosité: des langages comme ADA ou OCaml ne se prêtent pas à l'exercice ?
Je ne connais pas ces langages. Comme il a été dit précédemment, le C
est le langage le plus "universel". Même si ce n'est pas toujours le plus adapté, on peut tout faire avec.
Je n'en disconviens pas - mais cela justifie-t-il ton "Hormis le C, point de salut" ?
Effectivement, il y l'assembleur qui est l'arme absolue. Utilisable dans toutes les situations possibles, sur n'importe quel matériel. Bon, coté portabilité, c'est pas ça. Et puis, pour programmer plus que quelques lignes, il faut être bien accroché.
Ce que je veux dire, c'est que on trouve toujours (ou presque) un compilateur C pour un micro donné. Ce qui n'est pas le cas les autres langages. Et le C est tellement bas niveau (on pourrait presque dire que c'est une surcouche de l'assembleur) que l'on peut générer du code pour tous les besoins. J'ai un système qui tourne avec 8Ko de ROM et 256 octets de RAM. A part l'assembleur et le C, je ne connais pas de langage adapté. Et surtout, je ne connais pas d'autre langage qui possède un compilateur conçu pour mon micro. Attention, je n'ai pas dit que le C est le langage idéal ou le plus universel ou quoi que ce soit d'autre. Je dis qu'on trouve toujours un compilateur C à se mettre sous la main. Et dans certains cas particuliers, genre temps réel dur, en C tout est sous contrôle. Avec d'autres langages (y compris C++), on ne maitrise pas tout.
Nicolas
Eric Brunel
On Sun, 30 Sep 2007 23:33:43 +0200, jean-michel bain-cornu wrote:
En quoi donc d'aucuns supposent-ils que le typage statique est un avantage ?
Tu dis ça parce que tu as l'habitude d'être entre gens de bonne compagnie ici... Va sur fr.comp.developpement et essaie de leur parler de Python, tu vas voir comment tu vas te faire déchirer... Je me suis désabonné du groupe rien que pour ça... -- python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
En quoi donc d'aucuns supposent-ils que le typage statique est un
avantage ?
Tu dis ça parce que tu as l'habitude d'être entre gens de bonne compagnie
ici... Va sur fr.comp.developpement et essaie de leur parler de Python, tu
vas voir comment tu vas te faire déchirer... Je me suis désabonné du
groupe rien que pour ça...
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
On Sun, 30 Sep 2007 23:33:43 +0200, jean-michel bain-cornu wrote:
En quoi donc d'aucuns supposent-ils que le typage statique est un avantage ?
Tu dis ça parce que tu as l'habitude d'être entre gens de bonne compagnie ici... Va sur fr.comp.developpement et essaie de leur parler de Python, tu vas voir comment tu vas te faire déchirer... Je me suis désabonné du groupe rien que pour ça... -- python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
NicolasP
Salut !
0 or 1? My compromise of 0.5
;o) ça pourrait déboucher sur un nouveau concept de langage...
En logique floue par exemple...
Nicolas
Salut !
0 or 1? My compromise of 0.5
;o) ça pourrait déboucher sur un nouveau concept de langage...
