Pour ou contre elif ?
Alexandre Bique
En ce qui me concerne, pour !
--
Alexandre Bique
{Yaka,Gistr} 2009
Matthieu Garrigues
--
Garrigues Matthieu
EPITA 2009
Tel : 06.64.69.43.92
Alexandre Bique
<matthieu....@gmail.com> wrote:
> tu parle de quoi? de la macro?
macro ? non, notre compilateur n'a pas de preprocesseur (ce qui n'empeche
pas d'utiliser le preprocesseur du C par dessus du D, mais bon useless...).
Je parle de :
if (A)
B;
else if (C)
D;
else
E;
qui pourrait s'ecrire
if (A)
B;
elif (C) // sucre
D;
else
E;
Matthieu Garrigues
Moi je suis contre, je trouve que else if c'est plus explicite,
et pas telement si long a taper
Alexandre Bique
<matthieu....@gmail.com> wrote:
> Moi je suis contre, je trouve que else if c'est plus explicite,
> et pas telement si long a taper
faire ? Moi je trouve que elif a parfaitement sa place. Et dans les
langages ou il est utilise, il n'y a pas d'ambiguite lors de la relecture.
Julien Quintard
bonne idee, principalement parceque 1) il n'y a pas de difficulte
a avoir "else if" niveau syntaxe 2) les gens qui codent en
C/C++/Java/D et autres sont habitues a "else if".
--
JmQ
Alexandre Bique
Peut-etre que ce que l'on n'utilise pas ne nous manque pas, mais
peut-etre qu'une fois habitue, on dirait "ah un langage sans
elif, c'est vraiment des couillons les mecs qui l'ont fait...".
Moi je vois que :
- ca peut etre agreable suivant la personne, et ca n'empeche pas
l'utilisateur de ne pas s'en servir.
- Je pense que ca n'engendre pas d'ambiguites.
- Ton emacs peut facilement transformer lors de l'affichage un
elif en else if si tu es allergique au elif. (cf le mode qui
transforme MaClasse en Ma_Classe lors de l'affichage).
Sans compter que 3 caracteres ca peut eviter de peter les 80
colones :-P
Julien Quintard
> peut-etre qu'une fois habitue, on dirait "ah un langage sans
> elif, c'est vraiment des couillons les mecs qui l'ont fait...".
Ca en effet tu as raison, c'est possible.
Neanmoins, je pense que fournir plusieures manieres de faire la
meme chose c'est une mauvaise idee. Il faut juste prendre l'un ou
l'autre et en l'occurence, je pense que else if, les gens y sont habitues
et elif n'apporte rien sinon des caracteres en moins.
De plus certains langages utilisent elif, elsif, elseif donc franchement
c'est chaint de savoir. Au moins avec else if, tu sais que tu colles a la
syntaxe C.
Apres ce n'est que mon point de vue, a vous de choisir :)
--
JmQ
Alexandre Bique
Je dirais qu'il y a deux type de sucres :
- ceux qui foutent la merde comme pouvoir ecrire char a[]; et char[] a;.
Ils
entrainnent des ambiguites car au final on peut ecrire char [4]a[5]; ce
qui
ne veut plus rien dire.
- ceux qui sont claires et sans ambiguites :
- a *= b + c; <=> a = a * (b + c);
- elif <=> else if
- if (a) b.doSomething; <=> a && b.doSomething;
- b.doSomething; <=> b.doSomething(); (vrai en D et si on veux la
delegate, &)
Donc je considere qu'elif n'est pas un sucre negatif qui va troubler et
perdre
le prorammeur.
Matías Larre Borges
>
> Je dirais qu'il y a deux type de sucres :
> - elif <=> else if
> Donc je considere qu'elif n'est pas un sucre negatif qui va troubler et
> perdre
> le prorammeur.
>
Pourquoi elif et pas elseif ? ou elsif ?
Moi je sais pas trop quoi penser de tout ca. En regle generale je
n'aime pas beaucoup le code avec trop d'imbrications dans les blocs
conditionnels.
Pour moi un bloc conditionnel se doit d'etre binaire. Lorsqu'on
commence a rajouter plus de cas, ca veut dire qu'on est en train de
compliquer notre fonction et qu'il faut se poser la question de
l'utilite d'une fonction chapeau.
--
Matías LARRE BORGES
matias.la...@epita.fr
Alexandre Bique
<lan...@gmail.com> wrote:
> Pourquoi elif et pas elseif ? ou elsif ?
> Moi je sais pas trop quoi penser de tout ca. En regle generale je
> n'aime pas beaucoup le code avec trop d'imbrications dans les blocs
> conditionnels.
> Pour moi un bloc conditionnel se doit d'etre binaire. Lorsqu'on
> commence a rajouter plus de cas, ca veut dire qu'on est en train de
> compliquer notre fonction et qu'il faut se poser la question de
> l'utilite d'une fonction chapeau.
Je ne te contredirais pas sur ce point, mais bon l'exception confirmant
la regle, il existe des cas ou ce que tu dis est faux.
Tu peux par exemple relire le code d'un autre mec, le trouver degueu,
le relire une seconde fois, une troisieme fois etc... puis finir par
comprendre ce que le mec avait en tete, son point de vue et dire "ok
pourquoi pas".
Je dis ca car je pense qu'il ne faut pas dire : "utiliser elif engendre
des cas negatifs, je t'empecherais donc de l'utiliser pour ton bien,
(et je te batiserais chretiens toi et toute ta famille mouhahaha...
bref je m'ecarte)". Qui fait l'ange, fait la bete.
Matías Larre Borges
>
> Je dis ca car je pense qu'il ne faut pas dire : "utiliser elif engendre
> des cas negatifs, je t'empecherais donc de l'utiliser pour ton bien,
> (et je te batiserais chretiens toi et toute ta famille mouhahaha...
> bref je m'ecarte)". Qui fait l'ange, fait la bete.
>
Ouais je suis d'accord qu'empecher l'utilisation de quelquechose de
peur que ca engendre des cas negatifs est loin d'etre un argument.
Franchement je ne suis pas contre mais je prefererais un switch case
qui gere differents types de conditions (en terme de presentation dans
un fichier je trouve ca plus zoli [-:) plutot qu'un elif.
Arkanosis
> je pense que fournir plusieures manieres de faire la
> meme chose c'est une mauvaise idee. Il faut juste prendre l'un ou
> l'autre et en l'occurence, je pense que else if, les gens y sont habitues
> et elif n'apporte rien sinon des caracteres en moins.
Même avis sur la question.
Maintenant ce n'est pas vraiment critique.
--
Arkanosis
Alexandre Bique
<lan...@gmail.com> wrote:
> Franchement je ne suis pas contre
> mais je prefererais un switch case
> qui gere differents types de conditions (en terme de presentation dans
> un fichier je trouve ca plus zoli [-:) plutot qu'un elif.
Le switch case du D accepte des expressions donc tu peux faire un switch
sur une classe ou une chaine de carateres. Maintenant un switch n'est
pas bien plus qu'un multiplexeur donc tu lui donne x en entree et il
choisie la bonne voie pour toi. Donc pas d'expressions complexes.
Maintenant si tu as une idee geniale pour faire un nouveau genre de
switch plus sofistique c'est le bon endroit pour exprimer ton
imagination ;-) (tu pourrais creer un nouveau thread par contre).
Alexandre Bique
Au final qu'elle est ta position ? Pour ? Contre ? Osef ?
Je devrais peut-etre ouvrir une page sur le wiki pour faire un bilan
sur le elif (les pour et les contres) et creer un ticket.
Matthieu Garrigues
moi je trouve que c'est pas top d'avoir 40 solutions pour écrire la meme chose.Les gens qui programme
avec le langague doivent etre capable de comprendre n'importe quelle source quelque soit leur abitudes
de programations.
Pour moi, il devrait pas avoir plusieurs facon de programmer en D. La on parle d'un seul mot clef ok mais
c'est juste le principe qui me derange.
Conclusion : C'est bien d'avoir pasce le langage est plus souple, il s'adapte plus aux abitudes du programmeur
, mais en meme temps en étant plus souple on degrade la lisibilité du code, si n mot cefs signifient la meme chose,
le lecteur doit apprendre n mot clefs alors que il aurait pu en apprendre qu'un seul. De plus, pour un novice, elif n'est pas
forcement associé a else if...
Alexandre Bique
<matthieu....@gmail.com> wrote:
> moi je trouve que c'est pas top d'avoir 40 solutions pour écrire la meme
> chose.
``a += b;'' ou ``a = a + b;'' ? :p
> Les gens qui programme
> avec le langague doivent etre capable de comprendre n'importe quelle
> source
> quelque soit leur abitudes
>
> de programations.
>
> Pour moi, il devrait pas avoir plusieurs facon de programmer en D. La on
> parle d'un seul mot clef ok mais
>
> c'est juste le principe qui me derange.
>
> Conclusion : C'est bien d'avoir pasce le langage est plus souple, il
> s'adapte plus aux abitudes du programmeur
>
> , mais en meme temps en étant plus souple on degrade la lisibilité du
> code,
> si n mot cefs signifient la meme chose,
>
> le lecteur doit apprendre n mot clefs alors que il aurait pu en apprendre
> qu'un seul. De plus, pour un novice, elif n'est pas
>
> forcement associé a else if...
Je te repondrais que ca fait mal au cul d'apprendre a utiliser
des outils puissant (le C++, vim, emacs, gud etc...). Certes notepad
c'est sympas et a portee de tout le monde. Mais pas tres interressant
face a emacs ou vim apres quelques jours (voir quelques heures)
d'apprentissage.
Arkanosis
> Au final qu'elle est ta position ? Pour ? Contre ? Osef ?
> Je devrais peut-etre ouvrir une page sur le wiki pour faire un bilan
> sur le elif (les pour et les contres) et creer un ticket.
Plutôt contre avec une très légère tendance osef (mais très très
légère hein ^^).
Je vais pas reprendre l'argument de Julien et Matthieu, mais je
l'appuie fortement. Voir parfois else if et parfois elif ça va être
c****t, sans compter les trolls sur les coding-style, ceux qui vont
imposer le else if, ceux qui vont imposer le elif, et ceux qui
n'imposeront rien et qui ne seront pas consistants...
Le 22 juin 2008 03:54, Alexandre Bique <bique.a...@gmail.com> a écrit :
> ``a += b;'' ou ``a = a + b;'' ? :p
T'es pas crédible : t'es bien placé pour savoir que ce n'est pas du
tout équivalent, que ce soit en D ou en C++ d'ailleurs :p
--
Arkanosis
Quentin Raynaud
suivantes :
1/ elif ne gêne en rien la lecture, c'est intuitif et personne ne sera
abasoudi par le mot clef en le voyant pour la première fois, ne pas
l'utiliser ne sera pas non plus un problème, comme tout sucre, c'est
pas forcément nécessaire.
2/ elif a l'avantage incroyable du point de vue compilateur de lier
intrinsèquement une volée de tests, ce qui, à condition d'avoir de la
classe, du temps et des neuronnes en bon état de fonctionnement,
permet d'en profiter pour trouver des éléments sur les tests
permettant d'optimiser l'embranchement à l'exécution. Par exemple, le
cas suivant, typique :
int a = ...;
if (a < 0)
...
elif (a < 8)
...
elif (a < 18)
...
else
...
Peut "intuitivement" s'optimiser, pour transformer la recherche,
normalement linéaire, du cas à exécuter, en une recherche
dichotomique. Il doit exister un tas de cas symptomatiques de ce genre
sur lesquels des optimisations sont possibles. Donc pourquoi se gâcher
cette possibilité d'optim' dans le futur alors qu'on pourrait la
garder sans gêner qui que ce soit ?
Matías Larre Borges
>
> 2/ elif a l'avantage incroyable du point de vue compilateur de lier
> intrinsèquement une volée de tests, ce qui, à condition d'avoir de la
> classe, du temps et des neuronnes en bon état de fonctionnement,
> permet d'en profiter pour trouver des éléments sur les tests
> permettant d'optimiser l'embranchement à l'exécution.
Avantage que n'aurait pas "else if" ?
> Par exemple, le cas suivant, typique :
> int a = ...;
> if (a < 0)
> ...
> elif (a < 8)
> ...
> elif (a < 18)
> ...
> else
> ...
Oui, pour ce cas là il est évident qu'on peut optimiser
l'embranchement à l'exécution, néanmoins ça c'est l'exemple type du
code où tu as envie de tuer son concepteur lorsque tu dois le relire.
S'il n'y a pas de commentaires à coté pour expliquer un minimum quoi
que ce soit, les disjonctions de cas de ce type sont tout simplement
imbitables.
Puis dans le cas:
int a = ...;
if (a < 0)
...
elif (c.is_open ())
...
elif (c.is_running ())
...
elif (a < 18)
...
else
...
ça devient un peu moins évident pour le compilateur d'optimiser quoi
que ce soit. Remarque dans cet exemple, ça reste parfaitement jouable.
Mais le principe est là, en mélangeant des tests très différents je
pense qu'on peut facilement faire perdre le fil au compilateur.
Pour le genre de tests dont tu parles, je préférerais une nouveau bloc
de contrôle. similaire à celui du switch case avec lequel le
programmeur explicite un certain nombre de pré-conditions: à savoir:
"je vais tester un certain nombre de choses et je te garantis que tu
peux les optimiser".
Je pense surtout qu'on gagnerait en lisibilité avec cette structure,
en effet ça ressemblerait beaucoup plus à une définition de fonction
en maths où l'on fait une disjonction de cas selon une variable
switch a
case < 0
....
case < 8
....
case > 18
....
(biensur faudrait changer les mots clefs switch et case pour
quelquechse de plus explicite)
ça pourrait même s'appliquer à plusieurs variables:
switch a,x
case a > 0; x < 0
....
case a = 0; x = 0
....
case a < 0; x > 0
etc...
Bref, je dis peut etre de la merde, j'ai un peu bu a la fete de la musique :-)
Julien Quintard
a un certain nombre de questions.
1) Est-on en train de developper un compilateur pour le langage D?
Si oui, la question ne se pose pas, on devrait s'en tenir au D et eviter meme
de rajouter du sucre.
Si non, alors la question de la syntaxe se pose en effet mais pas sous
forme de sucre mais bien sous forme d'une nouvelle syntaxe.
Dans un tel cas, la question est:
2) Veut-on rester proche des langages connus tels que C/C++/Java/D ou
essayons nous d'evoluer (tout en restant proche de ces syntaxes)?
Bref tout ca pour dire qu'il faudrait peut etre deja repondre a des questions
fondamentales avant de parler de sucre non?
De plus, le sucre peut s'ajouter plus tard, une fois le compilateur deja
bien avance.
--
JmQ
Alexandre Bique
> 1) ...
Oui car nous partons avec le D comme base. Et non car le D 1.0 ne
permet pas de faire ``void chiche(const A b);'' ou meme de faire
des methodes const. Ce qui engendre un langage incomplet. Je pense
rester proche du D le plus longtemps possible. Par exemple ajouter
elif ne m'empeche pas de compiler du D. Retirer le support de char a[];
m'empeche de compiler du D (j'ai deja supprimer le support de char a[];).
Ceci dit, Walter Bright dit lui meme que si un jour char a[]; lui pose
un probleme de grammaire, il le supprimera sans hesitations. Donc
c'est comme s'il ne faisait deja plus partit du langage...
> 2) ...
En attendant je n'ai pas de modification du langage suffisement radicale
pour dire que l'on ne compile plus le D. Je les accueil a bras ouvert,
car j'irais troller avec les mecs de tango pour leur dire d'utiliser mon
langage car il est mieux et que le D ca pue ^^ (opensource, mieux code,
plus de gens qui travaillent dessus, du sang frais, ...).
Conclusion : le D c'est une base, apres je vais pas hesiter a peter la
compatibilite si une bonne idee/amelioration se presente. Sinon ca serait
du D++ et le C++ montre que c'est pas une bonne chose.
Alexandre Bique
Continue de boire alors :-) Je trouve l'idee sympas. Apres c'est un cas
typique ou tu proposes plusieurs facons differentes de faire la meme chose.
Peut-etre que ca demondre une chose : les solutions unique c'est bien mais
une solution supplementaire peut aider a mieux presenter les choses.
Julien Quintard
> permet pas de faire ``void chiche(const A b);'' ou meme de faire
> des methodes const. Ce qui engendre un langage incomplet. Je pense
> rester proche du D le plus longtemps possible. Par exemple ajouter
> elif ne m'empeche pas de compiler du D. Retirer le support de char a[];
> m'empeche de compiler du D (j'ai deja supprimer le support de char a[];).
> Ceci dit, Walter Bright dit lui meme que si un jour char a[]; lui pose
> un probleme de grammaire, il le supprimera sans hesitations. Donc
> c'est comme s'il ne faisait deja plus partit du langage...
Pour le elif je suis d'accord que ca ne change rien mais pour char a[]
ca change puisque un code D qui utilise cette grammaire ne compilera
pas avec votre compilateur puisque, comme tu le dis, vous l'avez vire.
Non?
> En attendant je n'ai pas de modification du langage suffisement radicale
> pour dire que l'on ne compile plus le D. Je les accueil a bras ouvert,
> car j'irais troller avec les mecs de tango pour leur dire d'utiliser mon
> langage car il est mieux et que le D ca pue ^^ (opensource, mieux code,
> plus de gens qui travaillent dessus, du sang frais, ...).
>
> Conclusion : le D c'est une base, apres je vais pas hesiter a peter la
> compatibilite si une bonne idee/amelioration se presente. Sinon ca serait
> du D++ et le C++ montre que c'est pas une bonne chose.
Je comprends tout a fait. Cela dit je pense qu'il faut faire l'un ou l'autre:
rester proche du D sans rajouter de trucs ou creer un autre langage
car autant vous allez garder la compatibilite dmd -> dcompiler autant
un programme ecrit avec votre compilateur (e.g utilisant elif) ne pourra
etre compile avec dmd.
C'est la meme chose que de creer une syntaxe GNU Make parcequ'ils
en ont marre de la syntaxe Make qui est trop limitee. Au final ca cree
un nouveau langage qui d'un cote veut rester proche du Make d'origine
mais qui de l'autre veut s'en ecarter pour fournir des features avancees.
Mon point de vue est que c'est une mauvaise idee. Soit vous avez une
raison suffisante pour forker soit il faut garder la compatibilite totale
sans quoi, (1) soit votre compilateur ne sera pas utilise (peu probable
si il est open source); soit (2) les gens vont vouloir ajouter leur features
en voyant que vous avez deja rajoute des trucs et ca risque de tendre
vers un beau merdier.
--
JmQ
Axel Berardino
Nombre de langage récent ont adopté ce mot clé (eiffel ou ruby pour ne
citer qu'eux). Je rejoint Bique sur le fait que le développeur n'est
pas obligé de l'utiliser.
De plus le concept est très intuitif. Cette année, j'ai encadré les
ISBP sur les TP de C et l'une des questions qui est le plus revenue,
lors de l'apprentissage des structures de contrôle, était: "Comment je
fais pour faire un sinon si ?". Elles ont été assez étonné que je leur
réponde que le langage ne le supportait pas et qu'elle allait devoir
l'émuler à grand coup de else + if.
--
Berardino Axel
Yaka 2009 - MTI 2009
Enseignant en Bioinformatique à l'institut Sup'Biotech
Alexandre Bique
<julien....@gmail.com> wrote:
>> Oui car nous partons avec le D comme base. Et non car le D 1.0 ne
>> permet pas de faire ``void chiche(const A b);'' ou meme de faire
>> des methodes const. Ce qui engendre un langage incomplet. Je pense
>> rester proche du D le plus longtemps possible. Par exemple ajouter
>> elif ne m'empeche pas de compiler du D. Retirer le support de char a[];
>> m'empeche de compiler du D (j'ai deja supprimer le support de char
>> a[];).
>> Ceci dit, Walter Bright dit lui meme que si un jour char a[]; lui pose
>> un probleme de grammaire, il le supprimera sans hesitations. Donc
>> c'est comme s'il ne faisait deja plus partit du langage...
>
> Pour le elif je suis d'accord que ca ne change rien mais pour char a[]
> ca change puisque un code D qui utilise cette grammaire ne compilera
> pas avec votre compilateur puisque, comme tu le dis, vous l'avez vire.
> Non?
de merde. Neanmoins un mec qui code du d en faisant Type Variable; sera
compilable.
>> En attendant je n'ai pas de modification du langage suffisement radicale
>> pour dire que l'on ne compile plus le D. Je les accueil a bras ouvert,
>> car j'irais troller avec les mecs de tango pour leur dire d'utiliser mon
>> langage car il est mieux et que le D ca pue ^^ (opensource, mieux code,
>> plus de gens qui travaillent dessus, du sang frais, ...).
>>
>> Conclusion : le D c'est une base, apres je vais pas hesiter a peter la
>> compatibilite si une bonne idee/amelioration se presente. Sinon ca
>> serait
>> du D++ et le C++ montre que c'est pas une bonne chose.
>
> Je comprends tout a fait. Cela dit je pense qu'il faut faire l'un ou
> l'autre:
> rester proche du D sans rajouter de trucs ou creer un autre langage
> car autant vous allez garder la compatibilite dmd -> dcompiler autant
> un programme ecrit avec votre compilateur (e.g utilisant elif) ne pourra
> etre compile avec dmd.
>
> C'est la meme chose que de creer une syntaxe GNU Make parcequ'ils
> en ont marre de la syntaxe Make qui est trop limitee. Au final ca cree
> un nouveau langage qui d'un cote veut rester proche du Make d'origine
> mais qui de l'autre veut s'en ecarter pour fournir des features avancees.
Je pense qu'ils ont bien fait car je prefere de loins GNU Make. Puis
certainnes features de GNU Make sont vraiment bien genre toto-%: chiche-%
Je me demande pourquoi BSD Make ne les a pas implemente ? Par fierte ?
Franchement je comprends pas qu'ils soient satisfait de .c.o:
> Mon point de vue est que c'est une mauvaise idee. Soit vous avez une
> raison suffisante pour forker soit il faut garder la compatibilite totale
> sans quoi, (1) soit votre compilateur ne sera pas utilise (peu probable
> si il est open source); soit (2) les gens vont vouloir ajouter leur
> features
> en voyant que vous avez deja rajoute des trucs et ca risque de tendre
> vers un beau merdier.
Tu as raison. Il faut voir ce que donne le D 2.0 en details. Mais le 1.0
n'est pas suffisant et je perdrais mon temps si c'etait mon seul objectif.
En ce qui concerne le fait que n'importe qui veuille ajouter n'importe
quoi.
Pour le moment les seules personnes participant au projet sont des gens que
je connais. Je n'imagine pas accepter des inconnus avant que le projet ait
une bonne structure.
L'arborescence du projet se prete au devellopement de plusieurs langages
differents. Donc on peut avoir un langage stable et d'autres langages
experimentaux qui pourraient etre compatible entre eux si l'on peut avoir
un AST commun. (comme sait le faire le .NET)
Je prefere casser la compatibilite et etre fiere de mon travail, meme si
personne ne l'utilise plutot que faire quelque chose d'utilise mais dont
je ne suis pas fiere. Pour moi c'est une raison valable pour forker ;-)
De toute facons si le resultat est bon, des gens l'utiliseront.
Julien Quintard
> ISBP sur les TP de C et l'une des questions qui est le plus revenue,
> lors de l'apprentissage des structures de contrôle, était: "Comment je
> fais pour faire un sinon si ?". Elles ont été assez étonné que je leur
> réponde que le langage ne le supportait pas et qu'elle allait devoir
> l'émuler à grand coup de else + if.
C'est different je pense. Il y a l'apect programmeur et l'aspet compilateur.
Du point de vue du programmeur, clairement il est considere que "else
if (XXX) {}"
n'est pas un "else { if {XXX} {} }" mais bien le moyen de faire des
"sinon si".
Niveau compilateur, j'imagine (parceque ca fait quelques annees
que je n'y ai pas touche) qu'avec un LL(1) tu peux differencier un "else"
d'un "else if" et donc effectuer toutes les optimisations dont vous parlez.
--
JmQ
Julien Quintard
> de merde. Neanmoins un mec qui code du d en faisant Type Variable; sera
> compilable.
Donc la compatibilite n'est pas votre objectif. Je pense que vous sous-estime
l'importance de ce genre de decisions.
Il faut que ce soit clair pour tout le monde pour que votre projet puisse avoir
un avenir. Vous ne pouvez pas continuer a developper en exhibant l'interet
de la compatibilite tout en forkant la syntaxe :)
Prenez une decision, mettez tout a clair dans des documents de design
que les nouveaux venus puissent les lire avant de stupidement discuter
vos choix et la gestion du projet sera deja plus simple.
> Je pense qu'ils ont bien fait car je prefere de loins GNU Make. Puis
> certainnes features de GNU Make sont vraiment bien genre toto-%: chiche-%
> Je me demande pourquoi BSD Make ne les a pas implemente ? Par fierte ?
> Franchement je comprends pas qu'ils soient satisfait de .c.o:
Ben ils en l'ont pas fait surement par souci de compatibilite et de portabilite.
C'est ce qui limite tous les projets de ce genre :( Le bon cote c'est que ton
application pourra tourner 30 ans plus tard. Le mauvais point c'est que bien
entendu ils n'ont pas pense a tout des le debut et sont donc contraint
d'abandonner
des idees.
> Tu as raison. Il faut voir ce que donne le D 2.0 en details. Mais le 1.0
> n'est pas suffisant et je perdrais mon temps si c'etait mon seul objectif.
On est d'accord (meme si j'ai pas vraiment regarde D 1.0 :D).
> En ce qui concerne le fait que n'importe qui veuille ajouter n'importe quoi.
> Pour le moment les seules personnes participant au projet sont des gens que
> je connais. Je n'imagine pas accepter des inconnus avant que le projet ait
> une bonne structure.
Encore une fois, si vous pronez le free-software, ca va avec :)
> L'arborescence du projet se prete au devellopement de plusieurs langages
> differents. Donc on peut avoir un langage stable et d'autres langages
> experimentaux qui pourraient etre compatible entre eux si l'on peut avoir
> un AST commun. (comme sait le faire le .NET)
Oui ca en effet pourquoi pas mais c'est un detail a l'heure actuelle.
Tout ce que je dis c'est que la, vos objectifs ne sont pas bien etablis
et donc vous allez perdre beaucoup de temps a discuter des choses
qui finalement ne sont pas vraiment importantes ou completement hors-sujet
en fonction des objectifs.
Je pense qu'a l'origine votre idee c'etait clairement de faire un compilateur
D open-source. Si vous commencez a reflechir (et je vous en felicite,
ca se fait tellement rare ce genre de personnes), alors arretez vous
10 minutes, reflechissez a ce que vous voulez et mettez votre fil directeur
sur papier que ce soit clair pour tout le monde.
> Je prefere casser la compatibilite et etre fiere de mon travail, meme si
> personne ne l'utilise plutot que faire quelque chose d'utilise mais dont
> je ne suis pas fiere. Pour moi c'est une raison valable pour forker ;-)
>
> De toute facons si le resultat est bon, des gens l'utiliseront.
Je suis entierement d'accord avec toi mais encore une fois vous etes
un peu en contradiction entre l'aspet "compatibilite" et l'aspet "innovation".
Les deux ne se marient pas bien du tout, comme tu l'as dit pour le C++.
La clef de la compatibilite (a mon avis) c'est de garder une syntaxe
relativement
proche de celles qui sont maitrisees: C/C++/Java/D. Mis a part ca, les gens
s'adapteront facilement si votre langage est puissant, coherent mais surtout
rapide et sur.
--
JmQ
Alexandre Bique
Tu as raison sur ce point. On donne l'impression de pas trop savoir ou
l'on vas.
Ce serait une bonne chose de se reunir pour discuter des objectifs.
Julien Quintard
> l'on vas.
>
> Ce serait une bonne chose de se reunir pour discuter des objectifs.
C'est exactement mon point de vue en effet.
Le fait que vous ayez des idees c'est vraiment genial, je vous encourage
a remettre en questions les langages existants pour arriver a un langage
facile d'utilisation, performant et sur.
Peut etre lancer un nouveau thread et discuter de ce qui manque aux
langages actuels et ce qui est bien etc. et faire le tri pour arriver a un
consensus sur une liste de features coherente pour un nouveau langage.
Encore une fois, une fois le raisonnement mis sur papier, les gens ne
pourront pas dire: "Pfff ils sont cons, ils refont un truc plutot que de
contribuer au C++ ou au D" puisque derriere il y aura un vrai raisonnement.
A vos cerveaux :)
--
JmQ
Arkanosis
du char c[] est spécial, car il n'était là que pour imiter le C++, et
n'aurait jamais du exister.
Si on veut améliorer le D, autant commencer un nouveau langage qui
abandonne la syntaxe pourrie du C, comme Python / Ruby / Boo, voire
haskell. C# a voulu faire un super langage en partant de la syntaxe du
C (c'est plutôt pas mal en effet), il s'en retrouve à faire de
l'inférence de type avec des var x = ... c'est assez pitoyable :(
--
Arkanosis
Julien Quintard
> du char c[] est spécial, car il n'était là que pour imiter le C++, et
> n'aurait jamais du exister.
Ca tout le monde est d'accord la dessus mais il n'empeche que l'enlever
de votre compilateur rend votre compilateur non compatible.
> Si on veut améliorer le D, autant commencer un nouveau langage qui
> abandonne la syntaxe pourrie du C, comme Python / Ruby / Boo, voire
> haskell. C# a voulu faire un super langage en partant de la syntaxe du
> C (c'est plutôt pas mal en effet), il s'en retrouve à faire de
> l'inférence de type avec des var x = ... c'est assez pitoyable :(
Oula :)
Personnellement je ne suis pas d'accord.
Premierement j'imagine que la qualite de la syntaxe est surement tres
subjective finalement.
Mais surtout, je pense qu'il faut rester proche d'un langage naturel a
manipuler et donc (1) imperatif (2) semblable a ce qui est deja largement
utilise. Sans ces deux points, a mon avis, votre langage aura beau etre
genial, tout le monde s'en battera les couilles a coeur joie.
Quelques exemples: Ada est super puissant mais a part pour le temps-reel
personne ne l'utilise. J'imagine que les langages fonctionnels tels que
Haskell, OCaml etc. sont super mais personne ne veut faire des maths pour
creer une application.
--
JmQ