go

Le 28-11-2009, ? propos de
Re: go,
batyann811 ?crivait dans fr.comp.os.linux.debats :

Jo Kerr a écrit :

Quel gros nul ce Ritchie !
Il aurait pu demander conseil à batyann811. ;-)

A l'époque j'étais beaucoup trop jeune et donc pas dispo. Cependant il y
avait 100000 fois mieux : Niklaus Wirth.

Mouais... Affaire de goût. Le seul avantage de ce type, c'est
d'avoir rué contre le goto.

De plus les idées de Ritchie sur les enums ou l'absence de booleens ne
devaient pas être si bonne puisque Stroustrup s'est senti obligé d'y
apporter quelques corrections.

Remouais. Une autre référence pas controversée du tout.
Personnellement, l'évocation de ce type aurait plutôt tendance à me
faire vomir.

Cependant je ne doute pas que Ritchie a
fait ces choix en toute conscience. Il voulait un langage d'assez bas
niveau et certainement un compilateur assez simple à écrire. Le drame
c'est que son langage a trop bien marché...

Le drame, ce n'est pas que ce langage ait bien marché. Son drame,
c'est qu'il est utilisé dans plein de domaines où il existe des
langages bien mieux fichus. Le C, c'est avant tout pour de
l'écriture système. Lorsqu'on fait du calcul, on devrait utiliser le
Fortran qui a été écrit pour cela. Pour l'embarqué ou le sensible,
ADA est tout indiqué. Le problème est qu'on utilise du C (ou C++,
même combat) partout en partant du principe que c'est une panacée,
ce qui n'est pas le cas. Écrire un code C parfaitement portable et
qui récupère toutes les erreurs de toutes le fonctions, c'est un
sacré boulot et quasiment personne ne le fait, alors que c'est assez
trivial dans d'autres langages.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Nicolas George a écrit :

Ne me fais pas rire. Prendre Stroustrup comme référence !

Rire ! Mais c'est une bonne idée ça. Tu devrais essayer de temps en temps.

Je ne dis que Stroustrup est une référence (quel nom pénible au
passage). Niklaus Wirth en revanche...

JKB a écrit :

Mouais... Affaire de goût. Le seul avantage de ce type, c'est
d'avoir rué contre le goto.

Je trouve qu'il a quand même pondu des langages pas mal : Pascal, Modula-2.

Remouais. Une autre référence pas controversée du tout.
Personnellement, l'évocation de ce type aurait plutôt tendance à me
faire vomir.

Je dis juste qu'il a essayé de corriger (un peu) les enums du C et d'y
ajouter des booléens. Rien de plus. Et comme de toutes façons il a voulu
garder une certaine compatibilité avec le C...

Le drame, ce n'est pas que ce langage ait bien marché. Son drame,
c'est qu'il est utilisé dans plein de domaines où il existe des
langages bien mieux fichus. Le C, c'est avant tout pour de
l'écriture système. Lorsqu'on fait du calcul, on devrait utiliser le
Fortran qui a été écrit pour cela. Pour l'embarqué ou le sensible,
ADA est tout indiqué. Le problème est qu'on utilise du C (ou C++,
même combat) partout en partant du principe que c'est une panacée,
ce qui n'est pas le cas. Écrire un code C parfaitement portable et
qui récupère toutes les erreurs de toutes le fonctions, c'est un
sacré boulot et quasiment personne ne le fait, alors que c'est assez
trivial dans d'autres langages.

Je souscris à 100%. Quand je disait "trop bien marché" je voulais dire
qu'il a été utilisé par tout et pour tout.

JKB wrote:

Mouais... Affaire de goût. Le seul avantage de ce type, c'est
d'avoir rué contre le goto.

Je ne vois aucun probleme a utiliser GOTO quand cela est necessaire. En
particulier quand cela permet de ne pas s'embarquer dans des
imbrications de if.

Le 28-11-2009, ? propos de
Re: go,
batyann811 ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

Mouais... Affaire de goût. Le seul avantage de ce type, c'est
d'avoir rué contre le goto.

Je trouve qu'il a quand même pondu des langages pas mal : Pascal,

Il faudra un jour qu'on m'explique la différence _fondamentale_
entre C et Pascal. J'ai beau chercher, je ne vois pas bien.
On peut écrire un compilo Pascal à l'aide d'un préprocesseur et de
gcc (c'est même comme ça qu'on compile généralement du Pascal sous Unix).

Modula-2.

Même remarque.

Remouais. Une autre référence pas controversée du tout.
Personnellement, l'évocation de ce type aurait plutôt tendance à me
faire vomir.

Je dis juste qu'il a essayé de corriger (un peu) les enums du C et d'y
ajouter des booléens. Rien de plus. Et comme de toutes façons il a voulu
garder une certaine compatibilité avec le C...

Et alors ? C'est au programmeur de faire la différence. Entier,
booléen, énumération, pour le processeur, ça termine en entier
quel que soit le langage (sauf à adresser des bits directement).
La différence, c'est l'autorisation ou non du transtypage.
Maintenant, très clairement, si on interdit le transtypage
implicite, il faut _aussi_ pour être cohérent que le langage vérifie
à la volée les indices de tableaux, les longueurs de buffers et tous
les dépassements entiers qui peuvent survenir. Donc, soit on utilise
le C en étant conscient des problèmes de transtypages et de
dépassements de tous acabits, soit on utilise un langage plus
strict (mais avec tout ce qui vient dans le paquet).

Le drame, ce n'est pas que ce langage ait bien marché. Son drame,
c'est qu'il est utilisé dans plein de domaines où il existe des
langages bien mieux fichus. Le C, c'est avant tout pour de
l'écriture système. Lorsqu'on fait du calcul, on devrait utiliser le
Fortran qui a été écrit pour cela. Pour l'embarqué ou le sensible,
ADA est tout indiqué. Le problème est qu'on utilise du C (ou C++,
même combat) partout en partant du principe que c'est une panacée,
ce qui n'est pas le cas. Écrire un code C parfaitement portable et
qui récupère toutes les erreurs de toutes le fonctions, c'est un
sacré boulot et quasiment personne ne le fait, alors que c'est assez
trivial dans d'autres langages.

Je souscris à 100%. Quand je disait "trop bien marché" je voulais dire
qu'il a été utilisé par tout et pour tout.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 28-11-2009, ? propos de
Re: go,
Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :

JKB wrote:

Mouais... Affaire de goût. Le seul avantage de ce type, c'est
d'avoir rué contre le goto.

Je ne vois aucun probleme a utiliser GOTO quand cela est necessaire. En
particulier quand cela permet de ne pas s'embarquer dans des
imbrications de if.

Depuis que je ne code plus en Basic de base (le truc avec les
numéros de lignes, parce que même en Turbo Basic, je n'ai jamais
utilisé de goto), je n'ai plus _jamais_ utilisé ce truc et sans
imbriquer des if à n'en plus finir. Si pour éviter des constructions
de structures conditionnelles tu es contraint à l'utilisation du goto,
c'est que ton code a un sérieux problème de conception.

J'attends aussi l'argument du "le goto, ça évite au programme de
gérer la pile en passant d'un point à un autre d'une routine", parce
que c'est trivialement faux. Le goto en question, il fait beaucoup
plus de choses que de sauter à l'étiquette (il vire les varables
locales aux blocs, bidouille la pile, bref, plein de choses dans le
dos de l'utilisateur). Dans tous les cas, c'est préjudiciable
(lisibilité du code, côté spaghetti et surtout opérations sur la
pile et le tas).

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

JKB a écrit :

Il faudra un jour qu'on m'explique la différence _fondamentale_
entre C et Pascal. J'ai beau chercher, je ne vois pas bien.

Quelques trucs plutôt sympas à mon goût : de vrais enums, des types
intervales, les ensembles, le contrôle des bornes bornes des tableaux,
la gestion des chaînes de caractères largement plus simple qu'en C, pas
besoins de se faire chier avec un makefile et des '.h'. Tu peux trouver
que ça n'est pas fondamentale mais qu'est ce que c'est agréable à l'usage !

Il y a bien sûr des trucs en moins (les champs de bits) ou qui sont un
peu plus pénible : le point virgule en séparateur d'instruction (ça
c'est une vraie connerie).

On peut écrire un compilo Pascal à l'aide d'un préprocesseur et de
gcc (c'est même comme ça qu'on compile généralement du Pascal sous Unix).

Pas le préprocesseur du C alors... Après tout dépend de ce qu'est un
préprocesseur pour toi.

Modula-2.

Même remarque.

Assez peu de différences par rapport au pascal. Principalement un
système de module qui se rapproche plus des packages d'ADA et une
syntaxe qui evite les begin/end à répétition.

Et alors ? C'est au programmeur de faire la différence. Entier,
booléen, énumération, pour le processeur, ça termine en entier
quel que soit le langage (sauf à adresser des bits directement).
La différence, c'est l'autorisation ou non du transtypage.

Bof. Le programmeur c'est un être humain, il fait des erreurs alors
autant que le compilo en détecte un maximum. Après je ne sais pas
l'usage que tu as des enums mais pour l'usage que j'en ai je ne vois que
très peu de raisons de pourvoir les mélanger avec des entiers dans des
expressions ou de pouvoir les additionner entre eux. Mais si tu as des
exemples...

Maintenant, très clairement, si on interdit le transtypage
implicite, il faut _aussi_ pour être cohérent que le langage vérifie
à la volée les indices de tableaux, les longueurs de buffers et tous
les dépassements entiers qui peuvent survenir. Donc, soit on utilise
le C en étant conscient des problèmes de transtypages et de
dépassements de tous acabits, soit on utilise un langage plus
strict (mais avec tout ce qui vient dans le paquet).

Sinon Pascal, Modula et ADA font tous les contrôles dont tu parles et
c'est très bien. Aller pour te faire râler je rajoute Java à la liste
(sauf pour les dépassements d'entiers).

Le 28-11-2009, ? propos de
Re: go,
batyann811 ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

Il faudra un jour qu'on m'explique la différence _fondamentale_
entre C et Pascal. J'ai beau chercher, je ne vois pas bien.

Quelques trucs plutôt sympas à mon goût : de vrais enums, des types
intervales, les ensembles, le contrôle des bornes bornes des tableaux,
la gestion des chaînes de caractères largement plus simple qu'en C, pas
besoins de se faire chier avec un makefile et des '.h'. Tu peux trouver
que ça n'est pas fondamentale mais qu'est ce que c'est agréable à l'usage !

Il y a bien sûr des trucs en moins (les champs de bits) ou qui sont un
peu plus pénible : le point virgule en séparateur d'instruction (ça
c'est une vraie connerie).

Je parle de différences _fondamentales_ et non de garde-fous. Rien
n'empêche d'écrire un compilo C qui regarde les bornes des tableaux
(par exemple). Il n'y a aucune différence entre le C et le Pascal
for ces garde-fous (le 'var' n'est par exemple qu'une façon de
masquer un pointeur dans un passage d'argument).

On peut écrire un compilo Pascal à l'aide d'un préprocesseur et de
gcc (c'est même comme ça qu'on compile généralement du Pascal sous Unix).

Pas le préprocesseur du C alors... Après tout dépend de ce qu'est un
préprocesseur pour toi.

Il n'y a pas que le préprocesseur du C. On peut faire des tas de
trucs avec un vrai préprocesseur comme m4.

Modula-2.

Même remarque.

Assez peu de différences par rapport au pascal. Principalement un
système de module qui se rapproche plus des packages d'ADA et une
syntaxe qui evite les begin/end à répétition.

Et alors ? C'est au programmeur de faire la différence. Entier,
booléen, énumération, pour le processeur, ça termine en entier
quel que soit le langage (sauf à adresser des bits directement).
La différence, c'est l'autorisation ou non du transtypage.

Bof. Le programmeur c'est un être humain, il fait des erreurs alors
autant que le compilo en détecte un maximum.

Le compilo ne peut pas imaginer tous les usages de la syntaxe.
Après, c'est une histoire de compromis. En cela, Pascal est une
bouse parce qu'il part de l'unique principe qu'il 'sécurise' le C.

Après je ne sais pas
l'usage que tu as des enums mais pour l'usage que j'en ai je ne vois que
très peu de raisons de pourvoir les mélanger avec des entiers dans des
expressions ou de pouvoir les additionner entre eux. Mais si tu as des
exemples...

C'est au programmeur de savoir ce qu'il fait. Maintenant, un enum
peut parfaitement rentrer dans un switch, et le switch prend un
argument entier.

Maintenant, très clairement, si on interdit le transtypage
implicite, il faut _aussi_ pour être cohérent que le langage vérifie
à la volée les indices de tableaux, les longueurs de buffers et tous
les dépassements entiers qui peuvent survenir. Donc, soit on utilise
le C en étant conscient des problèmes de transtypages et de
dépassements de tous acabits, soit on utilise un langage plus
strict (mais avec tout ce qui vient dans le paquet).

Sinon Pascal, Modula et ADA font tous les contrôles dont tu parles et
c'est très bien. Aller pour te faire râler je rajoute Java à la liste
(sauf pour les dépassements d'entiers).

Non. Java t'impose la récupération des erreurs alors que dans
certains cas, tu sais par avance qu'il n'y a pas d'erreur. C'est
tout aussi con comme technique. Je te répète que c'est au
programmeur de savoir ce qu'il fait. On peut écrire du code crade
dans tous les langages. Le simple fait de rajouter des contraintes
se justifie aux marges, mais pas dans une utilisation standard.

Je te donne juste un exemple : en C, printf() renvoie un entier.
Imagine maintenant que tu doives récupérer toutes les erreurs en
provenance de printf(). Tu sais que lorsque tu attaques un tty tu
vas pouvoir écrire (sinon, ton système est mal fichu). Tu sais aussi
qu'il n'est pas forcément grave de perdre une information sur un
terminal. Imagine maintenant un programme de base qui crache des
informations sur un tty et qui doive récupérer toutes les erreurs de
_toutes_ les fonctions. Un cauchemar !

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

JKB a écrit :

Je parle de différences _fondamentales_ et non de garde-fous. Rien
n'empêche d'écrire un compilo C qui regarde les bornes des tableaux
(par exemple). Il n'y a aucune différence entre le C et le Pascal
for ces garde-fous (le 'var' n'est par exemple qu'une façon de
masquer un pointeur dans un passage d'argument).

Je trouve que tous ces garde-fous font une grande différence à l'usage.
Tous les compilos pascal, ADA ou Modula ont ces garde-fous à ma
connaissance. Pour le C je n'en connais pas (de toute façon je connais
que gcc et turbo c en son temps). J'ai bien essayé des trucs genre lint
ou splint mais bof...

Il n'y a pas que le préprocesseur du C. On peut faire des tas de
trucs avec un vrai préprocesseur comme m4.

Tu as un lien vers un préprocesseur qui traduit du pascal en C ?

Le compilo ne peut pas imaginer tous les usages de la syntaxe.
Après, c'est une histoire de compromis. En cela, Pascal est une
bouse parce qu'il part de l'unique principe qu'il 'sécurise' le C.

Moi je vois plutôt ça comme un pas dans la bonne direction. Et le C
comme un régression.

C'est au programmeur de savoir ce qu'il fait. Maintenant, un enum
peut parfaitement rentrer dans un switch, et le switch prend un
argument entier.

Là je ne vois pas trop ou tu veux en venir. En pascal ou en ADA tu peux
utiliser n'importe quel type scalaire dans l'équivalent du swicth. Avec
en plus pour l'ADA l'obligation de traiter tous les cas possible comme
ça pas de risque d'en oublier.

Non. Java t'impose la récupération des erreurs alors que dans
certains cas, tu sais par avance qu'il n'y a pas d'erreur. C'est
tout aussi con comme technique. Je te répète que c'est au
programmeur de savoir ce qu'il fait. On peut écrire du code crade
dans tous les langages. Le simple fait de rajouter des contraintes
se justifie aux marges, mais pas dans une utilisation standard.

Pour la récupération obligatoire des exceptions de Java c'est vrai que
c'est un peu lourd. Mais je l'avais glissé pour te faire râler. Fais
gaffe t'es à la limite du réflexe pavlovien. ;-)

Après pour ton "c'est au programmeur de savoir ce qu'il fait" je ne vois
pas en quoi le fait d'avoir ce que tu as nommé plus haut des garde-fous
l'empêche de savoir ce qu'il fait d'autant qu'au besoin on peut
contourner ces protections. Pour ma part je préfère laisser le
compilateur détecter le plus possible de mes erreurs.

batyann811 a écrit:

Le compilo ne peut pas imaginer tous les usages de la syntaxe.
Après, c'est une histoire de compromis. En cela, Pascal est une
bouse parce qu'il part de l'unique principe qu'il 'sécurise' le C.

Moi je vois plutôt ça comme un pas dans la bonne direction. Et le C
comme un régression.

Pascal est antérieur à C donc je ne vois pas comment Niklaus Wirth aurait
pu vouloir sécuriser quelque chose qui n'existait pas lorsqu'il a conçu
le Pascal.

Pour la récupération obligatoire des exceptions de Java c'est vrai que
c'est un peu lourd.

Il n'y a pas d'obligation de récupération des exception en Java. Java
met en oeuvre deux types d'exception. Les "checked exception" et les
"unchecked exception".

Les "checked exception" doivent être traitées *ou* être spécifiées dans
une clause throws.

Les "unchecked exception" peuvent être traitées et il n'est pas nécéssaire
de les spécifier dans une clause throws. Cela concerne les
RuntimeException,
Error et les dérivées de ces classes.

Lorsqu'un "unchecked exception" n'est pas traitée, c'est au thread courant
de la traiter au travers de son UncaughtExceptionHandler s'il en a un ou
à celui du ThreadGroup auquel il appartient.


--
Franck