Sur Slashdot, on trouve un article faisant référence à une proposition (sérieuse) de nouveau langage, qui voudrait être le successeur du C et du C++. Le draft de la spécification est très intéressant: il ne s'agit pas de construire un langage entièrement compatible avec le C/C++, mais qui facilite le portage. Le D serait compilé, linkable avec les lib C mais pas C++, sans préprocesseur, sans héritage multiple, sans templates et sans surcharge d'opérateur. Il implémenterait par contre un garbage-collector, un système de modules, les exceptions, unicode, un support pour le débuggage, et surtout une vrai gestion des tableaux (ce langage se destine entre autre aux numériciens).
On peut noter que l'auteur est quelqu'un de plutot sérieux et qui connait le sujet puisqu'il est l'auteur original du compilateur Zortech C++ et du compilateur C++
Digital Mars.
Aller plus loin
# Arf !
Posté par Anonyme . Évalué à 0.
NNAAAANNNNNN
sans héritage multiple,
NNNAAAANNNNNN
sans templates
NNAAAAANNNN
sans surcharge d'opérateur.
NNNAAAANNNNN
Il implémenterait par contre un garbage-collector
NAAAANNNNNNN
les exceptions
NNNAAAAANNNNN
C'est pas D qu'il aurait fallu l'appeler, c'est Java, parcequ'ils ont repris tous les defauts de java là.
[^] # Re: Arf !
Posté par kadreg . Évalué à 1.
Remarque, on peut donner un coups de CPP dans n'importe quel fichier de n'importe quel langage avant de compiler :)
[^] # Re: Arf !
Posté par Anonyme . Évalué à 0.
Le garbage collector peut être considéré comme un défaut, en fait il faudrait qu'il soit optionnel.
[^] # Re: Arf !
Posté par Yannick (site web personnel) . Évalué à 1.
Mais y'a quand même une chose qui m'inquete : On n'est pas en train de s'éssouffler à faire pleins de languages redondants ?
Il faudrait mieux ce concentrer a faire des languages extensibles et plus complets.
Pour commencer virons le perl pour le ruby (si c'est pas déjà en court...)
Je lilite également pour le fortan 2000 sur gcc !
[^] # Re: Arf !
Posté par Delaregue . Évalué à 1.
[^] # on se tais le troll!
Posté par Anonyme . Évalué à -1.
pourquoi pas le remplacer par visualbasic!
pfffffff n'importe quoi !
[^] # Re: on se tais le troll!
Posté par Yannick (site web personnel) . Évalué à 1.
D'abord, perl est basic ce sont deux langages trés différents : Le basic sert à programmer, le perl à traiter des fichiers texte. On mélange pas les torchons et les serviettes. Vouloir faire autre chose [du]/[avec du] perl, c'est vouloir transporter du sable avec un camion citerne !
A chaque langage, sa spécialité !
On fait pas de l'ia avec du php mais avec du lisp ou du prolog. On ne fait pas non plus une appli bureautique en shell unix.
Ensuite, le ruby faire la meme chose que le perl en mieux. Pourquoi s'empêcher d'avancer en diluant
les efforts de tous, en développant deux langages redondants ?
Je ne prétend pas détenir la vérité. Mais voila mon avis.
Merci d'argumenter les réponses.
[^] # Re: on se tais le troll!
Posté par kangs . Évalué à 1.
[^] # Re: on se tais le troll!
Posté par Yannick (site web personnel) . Évalué à -1.
Pour le reste...
[^] # Re: on se tais le troll!
Posté par Anonyme . Évalué à -1.
"traiter des chaines de caracteres"!
les modules qui lui ont ete ajoute' permet de
developper assez vite des applis tres completes
avec gui etc...
Par contre, pour faire de l'ia, je pense que detronner les fossiles sera dur.
pour le basic: no comment c un troll...
[^] # Re: Arf !
Posté par analogue o/ (site web personnel) . Évalué à 1.
Je m'imprime des docs au pieu pour ce soir !
[^] # Re: Arf !
Posté par Seth . Évalué à 1.
[^] # Re: Arf !
Posté par Anonyme . Évalué à 0.
alors qu'il en existe déjà d'excellent langage comme Ocaml par exemple http://caml.inria.fr(...)
[^] # Re: Arf !
Posté par Nelis (site web personnel) . Évalué à 1.
NNNAAAAANNNNN
Euh ... rassure moi ... Tu rigoles là ??
# Super ! Ca me manquait trop, le nouveau langage de la semaine...
Posté par TSelek . Évalué à 1.
Et puis on arrete pas de le dire ici: A, B, C ou D c'est fini tous ces trucs ! L'avenir c'est Java, on ne va se repeter toutes les heures quand-même !
Ah, c'est posté par Pamela 8p
[^] # Re: Super ! Ca me manquait trop, le nouveau langage de la semaine...
Posté par GP Le (site web personnel) . Évalué à -1.
et hop un petit -1
[^] # Re: Super ! Ca me manquait trop, le nouveau langage de la semaine...
Posté par Anonyme . Évalué à 0.
Ben putain il me tarde pas le futur !!!
Sinon ruby c'est deja plus plaisant que l'elephant du cafe ...
# YAL
Posté par Delaregue . Évalué à 1.
Meme pas le 10eme de la qualite de lisp, vieux de 50ans...
[^] # Re: YAL
Posté par Troy McClure (site web personnel) . Évalué à 1.
je prends l'exemple du calcul scientifique (je ne sais pas si D est satisfaisant à ce niveau la, mais bon..): il faut un langage le plus rapide possible à l'execution, qui soit parallelisable, qui ait une bonne gestion des tableaux, des nombres complexes...
actuellement il y a:
- le C, ok pour la rapidité si on fait attention, mais pas de nombre complexes, pas de gestion vraiment commode des tableaux
- le fortran 77: le plus rapide, mais un langage vraiment pourri avec des lacunes enormes
- le c++, il faut tout refaire (gestion des tableaux,usage intensif des templates si on veut que les perfs soient a la hauteur...), on aboutit a des codes qui ressemblent a tout sauf a du c++ et qui mettent des heures a compiler
- le fortran 90, pas trop mal foutu, assez complet mais avec une gestion des entrees/sorties lamentable, a mon gout, et quelques soucis de performance.
bref, moi je dois dire que je reve d'un mix entre C et f90.
[^] # Re: YAL
Posté par Delaregue . Évalué à 1.
[^] # Re: YAL
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
T'es vraiment sur de toi ? :-)
[^] # List
Posté par kadreg . Évalué à 1.
((((() (()))(())
declaration de classe :
()()(((()) ())((((
[^] # Re: List
Posté par Anonyme . Évalué à -1.
t'auras pas du le mettre en -1, ça mérite mieux
[^] # Re: List
Posté par Delaregue . Évalué à 1.
(propriete :accessor))
[^] # Re: List
Posté par Anonyme . Évalué à 0.
[^] # Re: List
Posté par Delaregue . Évalué à 1.
[^] # Re: YAL
Posté par Delaregue . Évalué à 1.
Quant a la vitesse de calcul, il est temps de revoir ses prejuges ;-). Va donc faire une autre recherche sur google.
[^] # Re: YAL
Posté par Troy McClure (site web personnel) . Évalué à 1.
on parle ici de codes de calcul, cad ou le programme passe 99% de son temps dans des boucles du genre multiplication matrice x vecteur etc..
le lisp se base bien sur la recursivité, non ? donc c'est forcement beaucoup plus lent qu'une execution séquentielle (bien organisée)
[^] # Re: YAL
Posté par Delaregue . Évalué à 1.
(for case do dolist etc...)
La recursivite est en general prefere car presque toujours plus elegante.
Tu vas me dire que l'elegance n'est pas importante compare a l'efficacite. Je te repondrais que tu n'as raison qu'a 50%.
Cependant, Nombre d'implementation de lisp permettent d'optimiser la tail recursivite ce qui evite de faire des appels dans la stack et d'utiliser de la memoire.
>execution séquentielle (bien organisée)
La recursivite est sequentielle aussi. Tu voulais dire iteration?
[^] # Re: YAL
Posté par Troy McClure (site web personnel) . Évalué à 1.
pour l'élegance/efficacité je suis d'accord avec toi dans le cas général, mais dans la boucle la plus interne du programme, celle qui coûte le plus cher en cpu, je suis prêt à commettre toutes les horreurs imaginables pour gratter 5% de temps ;-)
et pour continuer a te chercher des noises, je dirais que si le lisp est élégant au niveau algorithmique, le code source ne l'est pas [tu me repondras peut etre que c'est des idées préconçues et je ne pourrai pas dire le contraire, j'ai jamais programmé en lisp...]
[^] # Re: YAL
Posté par Delaregue . Évalué à 1.
Je pensais de la meme facon quand j'ai commence lisp.
Mais c'est la toute la force de lisp par rapport a tout autre langages: le code lisp est fait de listes. Grace a cela, tu peux generer du code lisp a partir de lisp (cf macro). Lisp peut se redefinir lui-meme. Relis bien la phrase precedente. C'est pour cela que lisp a reussi a survivre pendant plus de 50 ans.
De plus, des editeurs tels que vim ou emacs rendent l'edition de code lisp tres aisee.
Those who do not understand Lisp are condemned to reinvent it poorly,
[^] # Re: YAL
Posté par Troy McClure (site web personnel) . Évalué à 1.
[^] # Re: YAL
Posté par Delaregue . Évalué à 1.
http://www.norvig.com/paip-preface.html#whylisp(...)
http://www-aig.jpl.nasa.gov/public/home/gat/lisp-study.html(...) (competition, plusieurs langages)
http://www.xanalys.com/software_tools/products/myths&legends.ht(...)
--
"The C language is particularly rich with ways of writing a program that totally hide the original design intent." - Stanley Chow
[^] # Re: YAL
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Stepanov (l'auteur de la STL) vient du monde Lisp et si il a utilisé C++ pour implémenter ses idées sur la programmation générique, c'est parce qu'il avait besoin de perfs et de typage fort que Lisp ne lui offrait pas, si je me souviens bien.
Bref non, Lisp est très loin d'offrir ce qu'offrent C++ ou Java actuellement (sans compter les libs standards de ces deux langages).
[^] # Re: YAL
Posté par Delaregue . Évalué à 1.
[^] # Re: YAL
Posté par Delaregue . Évalué à 1.
en 2 lignes:
http://www-aig.jpl.nasa.gov(...)
/public/home/gat/lisp-study.html
[^] # Re: YAL
Posté par Jak . Évalué à 1.
Ca doit être un bug de Dacode, mais c'est pas grave, car le lien est tout de même valide.
[^] # It's not a bug, it's a feature
Posté par kadreg . Évalué à 1.
[^] # Re: YAL
Posté par Delaregue . Évalué à 1.
Je suis sur qu'un des programmeurs aura lu le commentaire ;-)
[^] # Re: YAL
Posté par Anonyme . Évalué à 0.
[^] # Re: YAL
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Mais l'étude dit qu'il est plus rapide de developper en Lisp qu'en C++ ou Java. Oui, sur des petits utilitaires je veux bien, mais sur de vrais applis avec une GUI, qui sauve ses data en XML, et qui et network-transparent, je ne sais pas si ça serait pareil. En C++, il faut Qt et pas mal de boulot. En Java, c'est quasi-trivial. En lisp... t'as des widgets, un parseur XML, l'implementation d'HTTP, FTP, connection avec une DB, etc... (le tout standard de préférence) ?
Par ailleurs, l'étude dit aussi que les temps d'execution des programmes varient moins selon les compétences du programmeur en Lisp qu'en C++. D'un coté ça veut dire que même un médiocre programmeur Lisp va arriver à obtenir le meilleur temps d'execution possible, ou presque, et c'est vrai que c'est très bien.
Mais d'un autre coté ça veut dire que même si tu es bon, tu ne vas pas arriver à obtenir beaucoup mieux qu'un mauvais codeur, alors qu'en C++ ou Java tu sais que tu as encore de la marge pour optimiser ton code si nécéssaire.
Enfin je ne vois rien dans l'étude qui adresse la question du typage, ni des performances en programmation générique.
[^] # Re: YAL
Posté par kangs . Évalué à 1.
Je ne connais pas le Lisp, mais s'il permet à un mauvais programmeur de faire un code qui tourne correctement c'est sans doute parcequ'il laisse peut d'amplitude à l'imagination du programmeur.
Mais j'ai encore des doutes, un mauvais programmeur c'est qq qui ne sait pas choisir ces algo, qui ne respecte pas les règles, ...
[^] # Re: YAL
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Euh, oui, c'est vrai, mais quel est le rapport avec ce que j'ai dit ?
[^] # Re: YAL
Posté par kangs . Évalué à 1.
Lisp ne fera pas de miracle.
[^] # Re: YAL
Posté par Delaregue . Évalué à 1.
- Yahoo store a ete ecrit en lisp et a rapporte 50 millions de dollars ses developpeurs.
- un serveur web a ete ecrit completement en lisp et tu trouveras plusieurs applications qui l'utilisent a cette url (dont la maison blanche): http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html#appl(...)
- un autre lien: http://www.lisp.org/table/commercial-use.htm(...)
Je pourrais te citer beaucoup d'autres "vrais" applis.
Que t'offre Java ou C++ pour le data mining, la simulation etc...?
** tu as raison de souligner le manque de librairies "standards" avec lisp. Cela ne veut pas dire qui'il n'y a pas un "de facto" standard ex: widgets. Il existe plusieurs parseurs XML, sockets, connection avec Oracle, SQLServer, Postgres etc...
** le typage est bien present et peut etre ajoute a ton code si requis. Je ne vois pas pourquoi le probleme de la performance devrait etre addresse car il n'y a pas de probleme.
La plupart du temps, l'optimisation des performances se fait dans une ou deux fonctions. Rien ne t'empeche de faire des benchmarks et de loader la portion de code dans le langage le plus rapide
** un de mes atouts favoris de lisp:
Si une application ne peut pas s'arreter une seule minute et qu'il y a un bug, tu peux corriger ta fonction dans un thread pendant qu'un autre thread execute la fonction fautive et cela sans redemarrer. Les prochains threads executeront la fonction corrigee.
Stallman a dit une jour que tu devrais essayer lisp pour atteindre l'ultime illumination. Les autres langages paraitront bien fade apres cela.
[^] # Re: YAL
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
MS Office, Amazon...
> Que t'offre Java ou C++ pour le data mining, la simulation etc...?
Tu n'aura pas trop de mal à trouver des composants pour ça en C++, mais là on est d'accord, y a rien de standard. En Java, pour le data mining tu as JDBC. Pour la simulation, le terme est trop vague pour que je puisse répondre.
> Cela ne veut pas dire qui'il n'y a pas un "de facto" standard ex: widgets. Il existe plusieurs parseurs XML, sockets, connection avec Oracle, SQLServer, Postgres etc...
Justement, c'est l'une des grande forces de Java : tout ces trucs là sont standards dans la lib du langage. C++ ne fait hélas pas mieux de ce coté là.
> Je ne vois pas pourquoi le probleme de la performance devrait etre addresse car il n'y a pas de probleme.
C'est pas ce que dit l'étude. 30s au mieux pour le lisp, 11s pour du C++, et question mémoire c'est comme Java.
> Si une application ne peut pas s'arreter une seule minute et qu'il y a un bug
Je doute qu'il existe des cas reels ou cette feature presente un quelconque interet. C'est typiquement le genre de petit truc sympa qu'on trouve indispensable dans son langage favori, mais qui en pratique ne sert à rien.
> Stallman a dit une jour que tu devrais essayer lisp pour atteindre l'ultime illumination.
RMS est depuis longtemps obsolète sur le plan technique.
[^] # Re: YAL
Posté par Delaregue . Évalué à 1.
Tu sembles avoir l'approche "outil" de la programmation. C'est un peu comme les legos.
Quelqu'un plutot brillant un jour a cree un ensemble de composants que tu as pu assembler et tu t'amuses beaucoup. Mais tu ne peux pas vraiment construire tes propres composants.
Tant que tu travailles dans le mode des outils, tu ne vas jamais vraiment programme quelque chose.
Construire des outils pour les utilisateurs d'outils n'est pas la panacee. C'est en revanche vraiment excitant pour un utilisateur d'outils d'assembler ses legos.
Common lisp n'est pas un langage outil. Si tout le monde programmait en Common lisp, il n'aurait pas besoin d'outils stupides comme Java. Tu peux taper dans une poubelle et apprendre quelque notions de java a ceux qui en sort mais tu ne peux pas leur apprendre la programmation serieuse.
Quand je te parle de data mining tu penses tout de suite a ton outil, jdbc. Tu n'essayes pas de penser comment mieux representer l'information mais tu penses a ton connect (machin login password)
>Je doute qu'il existe des cas reels ou cette feature presente un quelconque interet. C'est typiquement le genre de petit truc sympa qu'on trouve indispensable dans son langage favori, mais qui en pratique ne sert à rien.
Enfin, dans ton monde d'outils, je comprends que le downtime n'a aucune signification pour toi.
>RMS est depuis longtemps obsolète sur le plan technique.
Avec quoi tu as redige ta page web....oui, oui xemacs c'est pas stallman!
[^] # Re: YAL
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Ben oui, coder, au bout d'un moment il faut bien que ça serve à quelque chose.
> Tu n'essayes pas de penser comment mieux representer l'information mais tu penses a ton connect (machin login password)
Et si je te parles de listes, est-ce que tu vas penser à comment mieux les representer ? Non, parce que le mec qui a implementé le lisp que tu utilises l'a fait avant toi. Et là c'est pareil, je veux faire une appli, j'utilise les outils qu'on m'offre plutot que de re-inventer la roue. Les gars qui ont fait ces outils connaissent sans doute le pb mieux que moi, et moi j'ai autre chose à faire.
Et pour la forme, jdbc va un peu au dela de la simple connection à une DB.
> Enfin, dans ton monde d'outils, je comprends que le downtime n'a aucune signification pour toi.
Bon, oublions le coté condescendant et assez ridicule de ta remarque et raisonnons calmement :
Un programme tourne, est buggé, et ne doit pas être arreté. Si il ne doit pas être arreté, c'est qu'il est critique, du genre serveur ou pilotage de centrale nucléaire. Supposons que tu as un fix testé. Est-il bien réaliste d'uploader du code neuf dans un programme dont tu ne connais pas l'état courant, d'abord parce il tourne depuis un certains temps, et ensuite parce qu'il y a un bug ?
Si ton bug c'est quelque chose du genre oublier d'effacer des fichiers temporaires par exemple, remplacer la fonction defectueuse ne va rien arranger, il faut aussi effacer les vieux fichiers laissés par la précédente.
Il est bien plus sur d'arreter, d'installer le fix et de repartir d'un état connu, ça évite les surprises.
Ensuite, si tu veux vraiment faire du High Availability (pour utiliser le terme habituel), tu le fais au niveau hard en doublant ou triplant tout. Et pour upgrader le soft, si je me souviens bien, tu descends l'une des deux machines, tu uploade le nouveau code, tu la redemarre, et pareil pour la suivante.
> Avec quoi tu as redige ta page web....oui, oui xemacs c'est pas stallman!
En effet non, XEmacs n'est pas de Stallman, tu confonds avec Emacs sans doute :-). Et meme Emacs n'est plus maintenu par rms depuis longtemps. Par ailleurs je ne vois pas le rapport, il a fait de bons softs, ça fait longtemps qu'il n'en fait plus. Et il n'a pas vraiment la reputation d'etre un excellent programmeur pour ce qu'il a fait, mais plutot d'un mec incapable de travailler hors du Lisp.
Un des mainteneurs de gcc disait il y a pas longtemps sur l'un des fr.comp.lang.* que lorsqu'il faisait du C, c'était pour coder un interpreteur lisp embarqué et qu'il faisait tout le reste dedans.
[^] # Re: YAL
Posté par Delaregue . Évalué à 1.
Je sais bien qu'xemacs n'est pas de stallman ainsi qu'une grande partie d'emacs d'ailleurs. Mon francais laisse a desirer quand j'ecris a la va-vite.
Une application ne doit pas etre lie au nucleaire pour etre critique. Un site web avec 15 000 utilisateurs par jour par example ; ce n'est pas enorme. Si tu as un downtime de 5 min pour 100 utilisateurs, c'est presque 10 heures de downtime cumule. Cela a beaucoup d'implication comme l'image de la compagnie, le manque a gagne qui peut etre de plusiers centaines de millier et le business sur ton dos (le moins marrant ;-). Doubler le hard ne servira pas a corriger ton bug evidemment. C'est un des avantages de lisp pour les applications haut de gamme.
J'entends beaucoup de "lisp n'a pas de librairies". Mais peu de personnes realisent que c'est tellement facile et rapide d'en creer.
C'est reinventer la roue? oui.
Tu as du te rendre compte que je n'aime pas java. (Je n'aime pas vraiment la programmation objet non plus. Je n'en ai pas besoin avec lisp mais si l'option reste dispo.). Java permet d'ecrire des applications complexes (a premiere vue) sans avoir a se creuser la tete. Mais on s'enferme dans un systeme ou l'on a meme pas besoin de penser...Je trouve que c'est regrettable. Java te pousse a assembler tes legos d'une facon pour resoudre un probleme. Lisp te permet de resoudre ton probleme de la maniere la plus elegante, la plus naturelle en te laissant le choix de l'abstraction.
Reinventer la roue devient productif...
Java n'est pas un probleme pour les petit projets. C'est le propos des outils de resoudre les petits problemes. Lisp te permet de creer les outils pour resoudre les grands projets, projets difficiles ou mal definis par le business.
[^] # Re: YAL
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Aucun problème.
> Un site web avec 15 000 utilisateurs par jour par example[...]
Oui, je suis tout à fait d'accord. Le pb reste entier, patcher un code "en live" pour corriger un problème est extrèmement risqué.
> Doubler le hard ne servira pas a corriger ton bug evidemment.
Non, mais a le corriger sans downtime, oui. Ou upgrader à la nouvelle version du code, c'est pareil.
> Mais peu de personnes realisent que c'est tellement facile et rapide d'en creer.
Mais pas aussi rapide que de ne pas avoir a les creer du tout. Combien de temps le type qui a fait un parser XML en Lisp a mis ? Est-il complètement documenté et maintenu ?
> Java permet d'ecrire des applications complexes (a premiere vue) sans avoir a se creuser la tete.
C'est (heureusement) le but de tout langage de programmation moderne.
> Lisp te permet de resoudre ton probleme de la maniere la plus elegante, la plus naturelle en te laissant le choix de l'abstraction.
Je comprends parfaitement ton point de vue esthétique, j'ai longtemps eu le meme, mais je m'en suis lassé, parce qu'au bout du compte l'important est de faire quelque chose d'utile, et non de satisfaire des criteres d'elegance qui n'importent qu'au programmeur.
> Reinventer la roue devient productif...
Demande ça au client qui attend son programme. :-)
[^] # Re: YAL
Posté par Vivi (site web personnel) . Évalué à 1.
Ah mais si il y a des nombres complexes en C (ISO C99)
[^] # Re: YAL
Posté par kangs . Évalué à 1.
"-le c++, il faut tout refaire (gestion des tableaux,usage intensif des templates si on veut que les perfs soient a la hauteur...), on aboutit a des codes qui ressemblent a tout sauf a du c++ et qui mettent des heures a compiler"
Gestion des tableaux : vector ?
Un code écrit en C++ avec l'usage intensif des templates ressembles à un code C++, sinon tu n'utilises pas le bon compilateur.
[^] # Re: YAL
Posté par Anonyme . Évalué à 0.
Probleme 1:
-----------
Le gros pb c'est que si tu veux des perfs excellentes il faut un langage avec peu d'abstraction. Imagine un langage avec des classes tu abstrait une structure de vecteur et tu fournit des operateurs +, *, - sur ces vecteurs.
Maintenant tu veux faire:
v = v1 + v2 + v3 + v4;
En general il va y avoir allocation de temporaires et les perfs s'ecroulent (gachis de bande passante memoire).
Les langages de haut niveau souffrent tres souvent de ce probleme. Une solution est fourni par l'utilisation massive des templates et expressions templates... Les templates fournissent un mecanisme sympa d'evaluation a la compilation qui permettent de marier perfs et abstractions. (Perso je ne met pas des heures pour compiler des expressions templates.. quel code, quel compilo).
Probleme 2:
-----------
ou pourquoi f77 est efficace.. l'aliasing.
Les problemes de perfs avec le C sont principalement lies a des problemes d'aliasing.
Un exemple de pb d'aliasing pour bien comprendre:
void add_vector(double *op1,
double *op2,
double *res);
// simple boucle for: res[i] = op1[i] + op2[i];
On ne peut pas charger op[i+1] avant que res[i] ne soit ecrit car ils peuvent correspondre a la meme adresse ! Cela empeche de paralleliser la boucle et d'utiliser les capacites super-scalaires des procs actuels.
Ces problemes sont resolus depuis C9X et l'introduction du mot cle restrict. Celui-ci permet de specifier que res, op1 et op2 ne se chevauchent pas.
Bref je ne vois pas ce qu'apporte D pour les codes numeriques. Et pour moi le D sans templates ca me parrait pas tres approprie pour avoir des perfs. D'autre part D me semble bien loin d'un mix C et f90.
[^] # Re: YAL
Posté par Wawet76 . Évalué à 1.
Y'aurait-il quelqu'un de compétent dans la salle pour confirmer/infirmer ça ?
[^] # Re: YAL
Posté par kangs . Évalué à 1.
[^] # Re: YAL
Posté par Troy McClure (site web personnel) . Évalué à 1.
g++ a certainement fait beaucoup de progrès depuis, mais la mauvaise impression initiale persite.
quand au mot cle restrict, oui c'est bien pratique pour combler la difference de perf entre C et f77, mais il faut faire aussi un certain nombre d'efforts pour forcer le compilateur à faire de bonnes optimisation.... enfin bon j'attend toujours le mix parfait entre C et f90, même si ce n'est pas D.
[^] # Re: YAL
Posté par Anonyme . Évalué à 0.
# y'en a vraiment qu'on rien a faire
Posté par Cobol ADA . Évalué à 1.
Si c pas du Java-like je sais pas ce que c'est
[^] # Re: y'en a vraiment qu'on rien a faire
Posté par Anonyme . Évalué à -1.
hopla -1
[^] # c du kk
Posté par Anonyme . Évalué à -1.
oui oui -1 ...
[^] # Re: y'en a vraiment qu'on rien a faire
Posté par Wawet76 . Évalué à 1.
...en oubliant que l'histoire de machine virtuelle, c'est un truc de la plate-forme Java, et non du langage Java.
En plus simple, ce qui serait intéressant est de connaitre les différence entre D et du Java compilé par gcc.
--
[^] # Re: y'en a vraiment qu'on rien a faire
Posté par manu manu . Évalué à 1.
enfin moi ce que j'en dit.
a propos de ce qui s'est dit plus haut, il est clair que pour le calcul, le C marche mieux (c'est presque pas un troll). Pour D, je vois pas l'utilité du GC (quand un prog est bien ecrit, les donnees sont detruites au bon moment!)
[^] # Re: y'en a vraiment qu'on rien a faire
Posté par Anonyme . Évalué à 0.
[^] # Re: y'en a vraiment qu'on rien a faire
Posté par Anonyme . Évalué à 0.
# Encore un autre langage...
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
[^] # Re: Encore un autre langage...
Posté par kadreg . Évalué à 1.
[^] # Re: Encore un autre langage...
Posté par Anonyme . Évalué à 0.
1/ le nom du langage ne devait pas être D mais L
car le langage C vient de BCLP encore un autre langage qui à donné le B puis donc le C !!
2/ un langage bien pensé évite de faire pas mal d'erreur lors de la conception (on prend les bonnes habitudes) et puis surtout lors de son utilisation. A part les boucles de calcul les perfs doivent s'analyser globalement un algo en n log n est plus efficace qu'un algo en n2 (AVEC n'importe quel langage !), mais justement les langages qui obligent à réfléchir et qui permettent une manipulation aisé de données complexes facilites des algo performants. (exemple des serveurs d'application en java, si si)
3/ mais bon, c'est sur que pour bien utiliser le LISP (lot of insipide and stupid parenthesis) sur une grosse appli faut vraiment se mettre en transe !
4/ a mon avis avec le C , JAVA et PYTHON voila déjà de quoi faire.
j'allais oublier
- le LOGO pour les enfants (ça semble naturel)
- et le FORTRAN grace auquel les plus agés ont ecrit les premiers compilateurs pour les autres langages.
[^] # Re: Encore un autre langage...
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
car le langage C vient de BCLP encore un autre langage qui à donné le B puis donc le C !!
C'est BCPL, pas BCLP.
http://cm.bell-labs.com/cm/cs/who/dmr/bcpl.html(...)
[^] # Re: Encore un autre langage...
Posté par Anonyme . Évalué à 0.
qui renvoie vers le lien http://merd.sourceforge.net/THANKS.html(...)
alors , blague ou réalité ce petit language ?
va savoir .....
NioTo
[^] # Re: Encore un autre langage...
Posté par Anonyme . Évalué à 0.
- réalité, pas encore.
- petit langage, pas tout à fait :)
Pixel.
[^] # Re: Encore un autre langage...
Posté par Anonyme . Évalué à -1.
[^] # Re: Encore un autre langage...
Posté par Anonyme . Évalué à 0.
http://www.chez.com/prigaux/cv-pixel.html(...)
[^] # Re: Encore un autre langage...
Posté par Chamelle Kolabo . Évalué à 1.
de CURL ( MIT c'est un autre niveau :)
http://curl.lcs.mit.edu/curl/(...)
Sinon a propos de chose Merd-ique , j ai pu apprecier a sa juste valeur le systeme de clonage
Mandrake, franchement pourquoi t as develloppe ca
en perl :( en python ca aurait nettement plus clair
[^] # Re: Encore un autre langage...
Posté par Romain Guy . Évalué à 1.
[^] # Re: Encore un autre langage...
Posté par Chamelle Kolabo . Évalué à 1.
En tout cas tu peux produire un document, rendre dynamique un client et en meme temps programmer coté serveur avec le meme langage .
Vu le merd-ier du web, cela n'est pas nulle.
"une truelle de HTML produit par XML/java, et
pour tenir le mortier, une brouette de javascript"
C'est comme essayer de comparer une betonneuse avec une traktopelle de chez mandrake .
Concretemment Lisp, Fortran, python, Curl ont chacun leurs domaines de predilection .
Mouai ... ricard, cacahouette et MERD
[^] # Re: Encore un autre langage...
Posté par Romain Guy . Évalué à 1.
[^] # Re: Encore un autre langage...
Posté par Anonyme . Évalué à 0.
Pour l'instant il n'y pas d'initiative dans ce domaine de programmation
<guylux>
[^] # Re: Encore un autre langage...
Posté par Romain Guy . Évalué à 1.
[^] # Re: Encore un autre langage...
Posté par Anonyme . Évalué à 0.
"Base de donnée objet orienté publication"
Il y a un projet en cours qui me semble interressant, melant la techno java/python/Zope
http://www.phabric.org/(...)
# Traduction du texte de DLFP-langue en français.
Posté par Anonyme . Évalué à -1.
linkable avec => avec édition de liens possible avec
les lib C => les bibliothèques du C
sans templates => sans modèles
un garbage-collector => un ramasse-miettes
le débuggage => la dévermination
DaLinuxFrenchPage => La page française sur Linux (version branlos inculte américanisé, nourri au mac-do et à la série américaine)
[^] # Re: Traduction du texte de DLFP-langue en français.
Posté par Anonyme . Évalué à -1.
Surtout en plein dans une bonne veine à troll sur les langages... Mmmm, je m'en réjouis à l'avance :-)
Avec une bonne allusion aux mac-do susceptible d'enclencher de troll maxi trolls sur la malbouffe et la mondialisation...
Encore bravo, trop trop fort !
[^] # Re: Traduction du texte de DLFP-langue en français.
Posté par Anonyme . Évalué à 0.
[^] # Re: Traduction du texte de DLFP-langue en français.
Posté par Anonyme . Évalué à 0.
[^] # Re: Traduction du texte de DLFP-langue en français.
Posté par Anonyme . Évalué à 0.
C'est bien tu as un dictionnaire anglais/francais, mais draft est mal traduit par brouillon dans ce cas, donc draft est préférable.
linkable avec => avec édition de liens possible avec
Ta proposition est imbuvable. Tu montres toi meme qu'il n'y a pas de solution en français, donc linkable est tout à fait acceptable.
les lib C => les bibliothèques du C
Non. Lib et library ce n'est pas pareil.
sans templates => sans modèles
Non plus.
un garbage-collector => un ramasse-miettes
Oui, c'est acceptable et meme assez utilisé.
le débuggage => la dévermination
Non. Particulièrement ridicule.
DaLinuxFrenchPage => La page française sur Linux (version branlos inculte américanisé, nourri au mac-do et à la série américaine)
Ca ne m'étonne pas qu'avec des propositions aussi stupides tu aies autant de préjugés. Je suppose que tu fais partie de ceux qui écrivent fièrement "cédérom". Allez, retourne
te branler sur le portrait de Toubonchercher d'aussi formidables traductions pour la langue française.[^] # Re: Traduction du texte de DLFP-langue en français.
Posté par ufoot (site web personnel) . Évalué à 1.
Ah???
Et Lib ca vient de quoi alors?
Logiciel Libre peut-etre...
[^] # Re: Traduction du texte de DLFP-langue en français.
Posté par Anonyme . Évalué à 0.
[^] # Re: Traduction du texte de DLFP-langue en français.
Posté par ufoot (site web personnel) . Évalué à 1.
Ni l'un ni l'autre, j'ai plutot tendance a dire:
- machine
- babasse
- becane
- ordino
- bousin
ou alors je donne un p'tit nom a mes machines, genre lors de l'installation par exemple, en plus c'est pratique ca permet de les identifier sur le reseau.
[^] # Re: Traduction du texte de DLFP-langue en français.
Posté par Anonyme . Évalué à 0.
ON t'oblige pas manger du roquefort; par contre ton poulet aux hormones tu peux te le garder. Les animaux, il faut les respecter.
[^] # Re: Traduction du texte de DLFP-langue en français.
Posté par Anonyme . Évalué à 0.
[^] # Re: Traduction du texte de DLFP-langue en français.
Posté par Anonyme . Évalué à 0.
Non, j'ai bien dit que rammasse-miette était une bonne proposition, les autres sont tout simplement ridicules, et j'aimerais mieux qu'on trouve des francisations acceptables. En l'occurence il n'y en a pas, donc reprendre les termes anglais reste la meilleure solution. Je ne suis pas opposé à de bonnes traductions, encore faut-il les trouver.
[^] # Re: Traduction du texte de DLFP-langue en français.
Posté par Wawet76 . Évalué à 1.
> Linux
Discution reccurente :D
"La Page Francophone sur Linux" est préférable si tu ne veux pas blesser tout nos amis hors-France.
--
Thomas, mi-Belge et mi-Francilien par naissance, breton de coeur et parisien de résidance principale.
[^] # Re: Traduction du texte de DLFP-langue en français.
Posté par Anonyme . Évalué à -1.
Thomas, mi-Belge et mi-Francilien par naissance, breton de coeur et parisien de résidance principale.
Alors l'orthographe, on va dire que c'est le cote belge :)
-1, car vraiment limite
[^] # Re: Traduction du texte de DLFP-langue en français.
Posté par Cru Kilu . Évalué à 1.
Ahhh hahahaaaa !!!!
[^] # Re: Traduction du texte de DLFP-langue en français.
Posté par Anonyme . Évalué à 0.
fait pas ch**r.
# Plus fort que Merd...
Posté par Anonyme . Évalué à 0.
Tout d'abord SousMerd supprimera toutes les fonctionnalités de Merd intéressantes, car je ne vois pas pourquoi je me ferai chier à les implémenter, si les utilisateurs, ces salauds, ne se sortent pas les doigts du cul pour les utiliser...
Par contre SousMerd sera beaucoup plus sûr à utiliser, car il forcera les programmeurs, ces enfoirés, à gérer toutes leurs exceptions de Merd.
C'est pour ça que j'ai déjà choisi le slogan suivant pour SousMerd : "A chacun son Merd !"
[^] # merci ...
Posté par deubeuliou . Évalué à -1.
[^] # Re: Plus fort que Merd...
Posté par Anonyme . Évalué à 0.
Ton langage a toute ses chances
# Encore des gas qui ont raté l'episode Java ;-)
Posté par Anonyme . Évalué à 0.
Ok, je comprend le blahblah sur :"ca fait pas ce que je veux" ... mais avant de reécrire 95% de la memechose juste parce que 5% ne sont pas OK, pourquoi ne pas tout simplement se servir de l'existent et l'adapter ? C'est de la perte de temps pure et simple !
Note au passage: Oui les sources du JDK de Sun sont dispo et OUI on peut y toucher, et Oui on peut diffuser le patch ! Mais la restriction est que l'on ne peut pas difuser le nouveau JDK ainsi modifié en l'appelant Java sans la validation du JCK (Test de compatibilité Java) fait en general par Sun (ou IBM).
Blagues
D, ils aurrait pu l'appeler :
YAJ (Yet Another Java) ou alors DINJ (Dinj Is Not Java) :o)
ou mieux: Db (D bémol) LOL !
:o)
Aller bon je retourne a mon duo favorit tux et duke...
[^] # Re: Encore des gas qui ont raté l'episode Java ;-)
Posté par Ramón Perez (site web personnel) . Évalué à -1.
Sinon bemol se dit flat en anglais
# Bah voyons
Posté par Anonyme . Évalué à 0.
pfff ...
Et puis bravo pour le nom c'est super original
# pffft.
Posté par Anonyme . Évalué à 0.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.