jeudi 10 avril

Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Astuces :: Suivi :: RDF

Articles précédents : Développeur

[17] KDevelop 2.0
[76] jdk1.3 pour Linux sur Alpha
[12] Qui développe des logiciels libres ?
[24] Opinions sur Mono
[50] Le concours de programmation ICFP 2001 est lancé!
[140] Comparatif jsp/php
[1] Review de Kylix
[50] FAQ sur le développement sous KDE
[39] Une version multi-plateforme du .NET de Microsoft: Ximian-Mono
[41] KIllustrator menacé par Adobe

Liens connexes

article slashdot (503 hits)
présentation du langage D (1086 hits)

Dépêche modérée par

penso

Développeur : Draft de la spécification du langage D

Posté par Troy McClure (page perso, ). Modéré le 16 août 2001.

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.

article slashdot (503 hits)
présentation du langage D (1086 hits)

> Lire la dépêche (101 commentaires, moyenne: 0,5).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Arf !

Posté par Anonyme () le 16/08/2001 à 14:54. (lien). Évalué à 0.

sans préprocesseur,
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 () le 16/08/2001 à 19:14. (lien). Évalué à 1.
sans préprocesseur,

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 () le 16/08/2001 à 19:14. (lien). Évalué à 0.
Ci dessus seuls l'absence de préprocesseur et de templates sont des défauts.
Le garbage collector peut être considéré comme un défaut, en fait il faudrait qu'il soit optionnel.

[^]Re: Arf !

Posté par Yannick (page perso, ) le 17/08/2001 à 07:43. (lien). Évalué à 1.
Je suis entierement d'accord là.

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 () le 17/08/2001 à 09:17. (lien). Évalué à 1.
  Un nouveau langage qui se differencie du reste du troupeau que par quelques ajouts est une preuve formelle que le langage ne va pas aller bien loin.
- [+] [^]on se tais le troll!
  
  Posté par Anonyme () le 17/08/2001 à 09:57. (lien). Évalué à -1.
  niquer perl !!
  pourquoi pas le remplacer par visualbasic!
  
  pfffffff n'importe quoi !
  - [^]Re: on se tais le troll!
    
    Posté par Yannick (page perso, ) le 17/08/2001 à 11:24. (lien). Évalué à 1.
    Pourquoi troll ? Réfléchit un peu...
    
    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 () le 17/08/2001 à 11:39. (lien). Évalué à 1.
      Vouloir faire autre chose que rien en VB c'est risqué : A chaque langage, sa spécialité !
      - [+] [^]Re: on se tais le troll!
        
        Posté par Yannick (page perso, ) le 17/08/2001 à 15:45. (lien). Évalué à -1.
        Pas d'accord : C'est partique pour faire des maquette ou des petits trucs vite fait.
        Pour le reste...
    - [+] [^]Re: on se tais le troll!
      
      Posté par Anonyme () le 20/08/2001 à 07:58. (lien). Évalué à -1.
      mmm, perl n'est pas fait QUE pour
      "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/ (page perso, ) le 10/09/2001 à 01:34. (lien). Évalué à 1.
  merci pour le conseil, je viens de matter un peu Ruby et ca a l'air de rulezer !
  
  Je m'imprime des docs au pieu pour ce soir !
  
  --
  Votez contre le cinéma sur DLFP: http://linuxfr.org/tracker/296.html
  Le lien pour voter est en haut à droite.

[^]Re: Arf !

Posté par Hugues Lemonnier () le 17/08/2001 à 07:44. (lien). Évalué à 1.
Bon, au moins ils ont laissé les pointeurs...

[^]Re: Arf !

Posté par Anonyme () le 17/08/2001 à 08:38. (lien). Évalué à 0.
je voit vraiment aucun interêt à ce langage
alors qu'il en existe déjà d'excellent langage comme Ocaml par exemple http://caml.inria.fr(...)

[^]Re: Arf !

Posté par Nelis (page perso, ) le 18/08/2001 à 12:58. (lien). Évalué à 1.
les exceptions
NNNAAAAANNNNN

Euh ... rassure moi ... Tu rigoles là ??

--
Vache qui rit, à moitié dans son lit

Super ! Ca me manquait trop, le nouveau langage de la semaine...

Posté par TSelek () le 16/08/2001 à 14:56. (lien). Évalué à 1.

Il n'a qu'a écrire une JVM ou un cross-compilo pour Ruby d'abord !
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 (page perso, ) le 16/08/2001 à 15:10. (lien). Évalué à -1.
Ah, je croyais que c'etait C# le langage d'avenir ? ;)

et hop un petit -1

[^]Re: Super ! Ca me manquait trop, le nouveau langage de la semaine...

Posté par Anonyme () le 17/08/2001 à 06:43. (lien). Évalué à 0.
Ah ouais c'est clair l'avenir c'est java.
Ben putain il me tarde pas le futur !!!

Sinon ruby c'est deja plus plaisant que l'elephant du cafe ...

YAL

Posté par Delaregue () le 16/08/2001 à 15:06. (lien). Évalué à 1.

pourquoi un autre langage? Pourquoi perdre son temps a re-inventer la route.
Meme pas le 10eme de la qualite de lisp, vieux de 50ans...

[^]Re: YAL

Posté par Troy McClure (page perso, ) le 16/08/2001 à 15:20. (lien). Évalué à 1.
parce qu'il y encore des besoins ?

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 () le 16/08/2001 à 15:23. (lien). Évalué à 1.
  lisp offre deja tout cela
  - [^]Re: YAL
    
    Posté par Guillaume Laurent (page perso, ) le 16/08/2001 à 15:38. (lien). Évalué à 1.
    Lisp offre un equivalent des templates et des classes, et et aussi rapide que C ou C++ pour du calcul ?
    
    T'es vraiment sur de toi ? :-)
    - [^]List
      
      Posté par kadreg () le 16/08/2001 à 15:40. (lien). Évalué à 1.
      Oui, regarde, une généricité :
      ((((() (()))(())
      
      declaration de classe :
      ()()(((()) ())((((
      - [+] [^]Re: List
        
        Posté par Anonyme () le 16/08/2001 à 15:50. (lien). Évalué à -1.
        mdr :))
        t'auras pas du le mettre en -1, ça mérite mieux
      - [^]Re: List
        
        Posté par Delaregue () le 16/08/2001 à 15:53. (lien). Évalué à 1.
        (defclass une-classe ()
        (propriete :accessor))
      - [^]Re: List
        
        Posté par Anonyme () le 16/08/2001 à 15:57. (lien). Évalué à 0.
        En fait, c'est un dérivé du morse.
        
        [^]Re: List
        
        Posté par Delaregue () le 16/08/2001 à 16:00. (lien). Évalué à 1.
        Et le penguin un derive du C ;-)
    - [^]Re: YAL
      
      Posté par Delaregue () le 16/08/2001 à 15:50. (lien). Évalué à 1.
      Cherche CLOS (common lisp object system qui fait parti du standard common lisp) sur google.
      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 (page perso, ) le 16/08/2001 à 15:59. (lien). Évalué à 1.
        pour la rapidité c'est vraiment dur a avaler...
        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 () le 16/08/2001 à 16:07. (lien). Évalué à 1.
        lisp ne se base pas forcement sur la recursivite. Il dispose d'iteration aussi.
        (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 (page perso, ) le 16/08/2001 à 16:20. (lien). Évalué à 1.
        oui je voulais dire itération :)
        
        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 () le 16/08/2001 à 16:33. (lien). Évalué à 1.
        Je suppose que tu fais allusion aux parentheses quand tu penses que le code source n'est pas elegant.
        
        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 (page perso, ) le 16/08/2001 à 16:41. (lien). Évalué à 1.
        bon ok, je m'incline :) quand j'aurai l'occasion, j'essairai de m'interesser à ce genre de langage, au moins pour m'en faire vraiment une idée.
        
        [^]Re: YAL
        
        Posté par Delaregue () le 16/08/2001 à 16:44. (lien). Évalué à 1.
        Quelques liens si cela t'interesse:
        
        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 (page perso, ) le 16/08/2001 à 19:49. (lien). Évalué à 1.
        Ah si CLOS est considéré comme "lisp standard" pourquoi pas. Et d'accord aussi pour la programmation générique, à quelques détails près : les perfs, et le typage fort.
        
        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 () le 17/08/2001 à 08:29. (lien). Évalué à 1.
        http://www-aig.jpl.nasa.gov/public/home/gat/lisp-study.html(...)
        
        [^]Re: YAL
        
        Posté par Delaregue () le 17/08/2001 à 08:31. (lien). Évalué à 1.
        Arg. Je n'arrive pas a afficher l'url complete.
        en 2 lignes:
        
        http://www-aig.jpl.nasa.gov(...)
        /public/home/gat/lisp-study.html
        
        [^]Re: YAL
        
        Posté par Jak () le 17/08/2001 à 08:41. (lien). Évalué à 1.
        > Arg. Je n'arrive pas a afficher l'url complete
        Ca doit être un bug de Dacode, mais c'est pas grave, car le lien est tout de même valide.
        
        --
        « Le savoir, n'est-ce pas, est un bien précieux. Trop précieux pour ne pas être partagé. »
        - Battologio d'Epanalepse, in De Cape et de Crocs, Acte VII (Ayroles & Masbou)
        
        [^]It's not a bug, it's a feature
        
        Posté par kadreg () le 17/08/2001 à 09:12. (lien). Évalué à 1.
        Si l'url est trop longue, il la coupe à l'affichage. Je trouve ca bien, ca allège les commentaires. Par contre, il faudrait un petit signe, style [...] pour montrer que l'url est visuellement incomplete.
        
        [^]Re: YAL
        
        Posté par Delaregue () le 17/08/2001 à 09:12. (lien). Évalué à 1.
        Ou faut il soumettre le bug?
        
        Je suis sur qu'un des programmeurs aura lu le commentaire ;-)
        
        [^]Re: YAL
        
        Posté par Anonyme () le 17/08/2001 à 22:55. (lien). Évalué à 0.
        c'est pas un bug, c'est volontaire, pour les url trop longues
        
        [^]Re: YAL
        
        Posté par Guillaume Laurent (page perso, ) le 17/08/2001 à 09:26. (lien). Évalué à 1.
        Interessant. Déjà l'idée de faire bosser plusieurs programmeurs séparement sur le même problème pour palier au différences de compétences est très bien.
        
        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 () le 17/08/2001 à 09:37. (lien). Évalué à 1.
        Houla, attention en C++ (comme en C) un mauvais programmeur ne pourra pas compter sur la qualité de son compilateur !
        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 (page perso, ) le 17/08/2001 à 13:07. (lien). Évalué à 1.
        > Houla, attention en C++ (comme en C) un mauvais programmeur ne pourra pas compter sur la qualité de son compilateur !
        
        Euh, oui, c'est vrai, mais quel est le rapport avec ce que j'ai dit ?
        
        [^]Re: YAL
        
        Posté par kangs () le 17/08/2001 à 13:11. (lien). Évalué à 1.
        "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."
        
        Lisp ne fera pas de miracle.
        
        [^]Re: YAL
        
        Posté par Delaregue () le 17/08/2001 à 10:54. (lien). Évalué à 1.
        ** Qu'est ce que tu appelles une vrai appli?
        
        - 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 (page perso, ) le 17/08/2001 à 13:20. (lien). Évalué à 1.
        > Qu'est ce que tu appelles une vrai appli?
        
        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 () le 17/08/2001 à 13:44. (lien). Évalué à 1.
        >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à.
        
        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 (page perso, ) le 17/08/2001 à 15:02. (lien). Évalué à 1.
        > Tu sembles avoir l'approche "outil" de la programmation. C'est un peu comme les legos.
        
        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 () le 17/08/2001 à 16:11. (lien). Évalué à 1.
        Cela n'etait pas mon intention de t'offenser. Merci d'accepter mes excuses.
        
        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 (page perso, ) le 17/08/2001 à 16:53. (lien). Évalué à 1.
        > Cela n'etait pas mon intention de t'offenser. Merci d'accepter mes excuses.
        
        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 (page perso, ) le 16/08/2001 à 16:14. (lien). Évalué à 1.
  mais pas de nombre complexes
  
  Ah mais si il y a des nombres complexes en C (ISO C99)
- [^]Re: YAL
  
  Posté par kangs () le 17/08/2001 à 09:10. (lien). Évalué à 1.
  Dans la nouvelle norme du C les nombres complexes existent.
  
  "-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 () le 17/08/2001 à 09:28. (lien). Évalué à 0.
  Deux problemes cles pour obtenir des perfs:
  
  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 (page perso, ) le 17/08/2001 à 10:18. (lien). Évalué à 1.
    J'ai entendu dire (toujours pareil, impossible de retrouver où...) que comme les références Java sont plus simple que la logique de pointeur en C, il y a plus de possibilités d'optimisation automatique par le compilateur. Il faudrait juste que les compilateurs Java rattrapent les dizaines d'années de retard par rapport aux compilateurs C.
    
    Y'aurait-il quelqu'un de compétent dans la salle pour confirmer/infirmer ça ?
    - [^]Re: YAL
      
      Posté par kangs () le 17/08/2001 à 11:14. (lien). Évalué à 1.
      La différence pointeur vs référence c'est surtout la facon de l'utiliser et pourquoi l'utiliser.
  - [^]Re: YAL
    
    Posté par Troy McClure (page perso, ) le 17/08/2001 à 11:33. (lien). Évalué à 1.
    honnetement ça fait longtemps que je n'ai plus fait de c++ dans des code de calcul, mais mes derniers essais remontent à l'époque d'egcs, avec les librairies Blitz++ et SL++ (sl++ est un projet abandonné, je crois), entierement basées sur les expression templates. Eh bien un code C++ de 3 lignes mettait 5 minutes à compiler, en bouffant 100Mo de mémoire...
    
    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 () le 16/08/2001 à 19:58. (lien). Évalué à 0.
ouais.. et scheme aussi ?

y'en a vraiment qu'on rien a faire

Posté par Cobol ADA () le 16/08/2001 à 15:14. (lien). Évalué à 1.

C bizarre mais les spec de ce langage ressemble fort a Java, pas de preproc, pas d'heritage multiple, pas de template, presence d'un garbage collector.
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 () le 16/08/2001 à 15:16. (lien). Évalué à -1.
C'est du Dava ?

hopla -1

[+] [^]c du kk

Posté par Anonyme () le 16/08/2001 à 15:30. (lien). Évalué à -1.
:)

oui oui -1 ...

[^]Re: y'en a vraiment qu'on rien a faire

Posté par Wawet76 (page perso, ) le 16/08/2001 à 15:55. (lien). Évalué à 1.
D'après la description de la news, les seules différences entre D et Java sont que D est compilé et linkable avec le C...

...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 () le 16/08/2001 à 17:34. (lien). Évalué à 1.
l'interet de Java, c'est surtout la machine virtuelle (c'est comme ca qu'il a ete "vendu"). Ici, on n'a pas l'air de parler de machine virtuelle...
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 () le 17/08/2001 à 06:45. (lien). Évalué à 0.
  C'est marrant la vm c'est ce que je trouve de plus pourri dans java :)
  - [^]Re: y'en a vraiment qu'on rien a faire
    
    Posté par Anonyme () le 17/08/2001 à 10:16. (lien). Évalué à 0.
    Tu dois kiffer la VM de .Net alors!!!

Encore un autre langage...

Posté par Guillaume Laurent (page perso, ) le 16/08/2001 à 15:39. (lien). Évalué à 1.

http://merd.sourceforge.net/(...)

[^]Re: Encore un autre langage...

Posté par kadreg () le 16/08/2001 à 15:42. (lien). Évalué à 1.
Avec un nom comme ca, c'est un langage qui pue :)
- [^]Re: Encore un autre langage...
  
  Posté par Anonyme () le 17/08/2001 à 15:45. (lien). Évalué à 0.
  quelques remarque en passant.
  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 (page perso, ) le 17/08/2001 à 15:59. (lien). Évalué à 1.
    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 !!
    
    C'est BCPL, pas BCLP.
    
    http://cm.bell-labs.com/cm/cs/who/dmr/bcpl.html(...)

[^]Re: Encore un autre langage...

Posté par Anonyme () le 16/08/2001 à 15:46. (lien). Évalué à 0.
J'aime bien la petite mouche en haut à droite
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 () le 16/08/2001 à 16:56. (lien). Évalué à 0.
  - blague, non.
  - réalité, pas encore.
  - petit langage, pas tout à fait :)
  
  Pixel.
  - [+] [^]Re: Encore un autre langage...
    
    Posté par Anonyme () le 16/08/2001 à 17:29. (lien). Évalué à -1.
    çà a l'air plutôt sympa comme langage, mais je connais aucun francophone qui osera le citer dans une discussion ou le mettre sur son cv.
    - [^]Re: Encore un autre langage...
      
      Posté par Anonyme () le 16/08/2001 à 19:30. (lien). Évalué à 0.
      ca vaut peut etre pas pour moi, mais bon je suis francophone et voici mon cv :)
      http://www.chez.com/prigaux/cv-pixel.html(...)
      - [^]Re: Encore un autre langage...
        
        Posté par Chamelle Kolabo (page perso, ) le 17/08/2001 à 08:17. (lien). Évalué à 1.
        Mouai, vu le merdier qu il y a sur le web, il serait plus interressant de regarder du cote
        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 (page perso, ) le 17/08/2001 à 09:12. (lien). Évalué à 1.
        Le Curl est vraiment NUL ! Et je parle en connaissance de cause, je l'ai essayé :)
        
        [^]Re: Encore un autre langage...
        
        Posté par Chamelle Kolabo (page perso, ) le 17/08/2001 à 12:23. (lien). Évalué à 1.
        Tiens donc ??
        
        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 (page perso, ) le 17/08/2001 à 14:50. (lien). Évalué à 1.
        Je le trouve nul d'un point de vue agrément de développement. A première vue j'étais vraiment emballé. Il ne s'agit que de mon opinion, forgé après avoir essayé la chose. Ce qui m'a surtout embêté c'était la taille du plugin, et le fait que cela ne soit disponible que sous Windows... et également les termes de la license... tu as vu le prix des royalties ?? Il y a beaucoup de bon là dedans (support XML, dynamisme, génération de documents, styles dans les chaînes, etc...) mais je considère qu'il y a certaines erreurs :)
        
        [^]Re: Encore un autre langage...
        
        Posté par Anonyme () le 17/08/2001 à 17:24. (lien). Évalué à 0.
        Mouai, d'ou l'interet de produire ce type de langage en Open Source.
        
        Pour l'instant il n'y pas d'initiative dans ce domaine de programmation
        
        <guylux>
        
        [^]Re: Encore un autre langage...
        
        Posté par Romain Guy (page perso, ) le 17/08/2001 à 18:03. (lien). Évalué à 1.
        Ah s'il avait été Open Source, je n'aurais pas dit ça puisque l'on aurait pu nous même y faire quelque chose. Mais là, ça semble mal parti. Il semblerait que les solutions lourdes Php/MySQL ou Java/XML/XSL (ou un mix improbable de ces trucs :) aient encore des beaux jours devant elles en ce qui concerne les générations dynamiques. Le groupe Apache est d'ailleurs super actif de ce point de vue (xml.apache.org).
        
        [^]Re: Encore un autre langage...
        
        Posté par Anonyme () le 19/08/2001 à 09:45. (lien). Évalué à 0.
        Mouai, je pense plutot pour un truc comme Zope.
        "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 () le 16/08/2001 à 16:58. (lien). Évalué à -1.

Le draft de la spécification => le brouillon de la spécification
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 () le 16/08/2001 à 17:26. (lien). Évalué à -1.
Merci, ça nous manquait beaucoup un maxi troll des familles sur l'anglais vs le français et sur le nom "dlfp".

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 () le 16/08/2001 à 18:13. (lien). Évalué à 0.
  N'empèche qu'il a raison.
  - [^]Re: Traduction du texte de DLFP-langue en français.
    
    Posté par Anonyme () le 16/08/2001 à 18:47. (lien). Évalué à 0.
    sur les deux premiers oui, d'accord, mais pour les autres termes, ça s'apparente à de la sodomisation de drosophile... moi j'utilise GDB (Gnu Debugger) et pas GDV.

[^]Re: Traduction du texte de DLFP-langue en français.

Posté par Anonyme () le 16/08/2001 à 19:33. (lien). Évalué à 0.
Le draft de la spécification => le brouillon de la spécification

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 Toubon~~ chercher d'aussi formidables traductions pour la langue française.
- [^]Re: Traduction du texte de DLFP-langue en français.
  
  Posté par ufoot (page perso, ) le 17/08/2001 à 07:24. (lien). Évalué à 1.
  > Non. Lib et library ce n'est pas pareil.
  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 () le 17/08/2001 à 23:07. (lien). Évalué à 0.
    Que "Lib" et "Library" soient deux mots différents est pourtant évident, d'autant que l'un est l'abréviation de l'autre. Tu dis "J'ai un PC" ou "J'ai un OP" ?
    - [^]Re: Traduction du texte de DLFP-langue en français.
      
      Posté par ufoot (page perso, ) le 19/08/2001 à 08:56. (lien). Évalué à 1.
      Tu dis "J'ai un PC" ou "J'ai un OP" ?
      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 () le 17/08/2001 à 08:55. (lien). Évalué à 0.
  Toutes les propositions tiennent, car elle sont créatrices. C'est bien souvent les gardiens de la conformité (dans ton style) qui appauvrissement un langue.
  
  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 () le 17/08/2001 à 09:15. (lien). Évalué à 0.
    Les idées créatrices est débiles tu peux te les garder.
  - [^]Re: Traduction du texte de DLFP-langue en français.
    
    Posté par Anonyme () le 17/08/2001 à 23:11. (lien). Évalué à 0.
    Toutes les propositions tiennent, car elle sont créatrices. C'est bien souvent les gardiens de la conformité (dans ton style) qui appauvrissement un langue.
    
    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 (page perso, ) le 16/08/2001 à 20:31. (lien). Évalué à 1.
> DaLinuxFrenchPage => La page française sur
> 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 () le 16/08/2001 à 21:20. (lien). É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 () le 17/08/2001 à 07:39. (lien). Évalué à 1.
  > ... et parisien ...
  
  Ahhh hahahaaaa !!!!

[^]Re: Traduction du texte de DLFP-langue en français.

Posté par Anonyme () le 16/08/2001 à 21:54. (lien). Évalué à 0.
t'as traduit (pas trop bien mais le sens est là), donc t'as compris. tout le monde a compris.
fait pas ch**r.

Plus fort que Merd...

Posté par Anonyme () le 17/08/2001 à 05:14. (lien). Évalué à 0.

Moi je vais faire la même chose avec Merd que D et Java on fait avec le C++ : je vais faire un sous langage de Merd que j'appelerai évidement SousMerd !

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 () le 17/08/2001 à 05:37. (lien). Évalué à -1.
merci pour ce moment de bonheur ...

[^]Re: Plus fort que Merd...

Posté par Anonyme () le 17/08/2001 à 09:18. (lien). Évalué à 0.
Visiblement plus en langage a de défauts, plus il lui manque de fonctionalités, plus il est lent et plus il a de chance de plaire à une large base de c*ll*s.

Ton langage a toute ses chances

Encore des gas qui ont raté l'episode Java ;-)

Posté par Anonyme () le 17/08/2001 à 09:24. (lien). Évalué à 0.

Non, vraiment je comprend pas certains developeurs : ils ont vraiment rien d'autre à faire de leur temps que de reecrire la roue ?

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 (page perso, ) le 17/08/2001 à 11:50. (lien). Évalué à -1.
Réécrire la roue c'est sympa comme idée....

Sinon bemol se dit flat en anglais

Bah voyons

Posté par Anonyme () le 17/08/2001 à 09:56. (lien). Évalué à 0.

Et pourquoi il écrit pas plutôt un compilo C# ça lui en ferait un troisième ...
pfff ...
Et puis bravo pour le nom c'est super original

pffft.

Posté par Anonyme () le 17/08/2001 à 19:20. (lien). Évalué à 0.

vive le C.

Revenir en haut de page

Articles précédents : Développeur

Liens connexes

Dépêche modérée par

Développeur : Draft de la spécification du langage D

Arf !

[^]Re: Arf !

[^]Re: Arf !

[^]Re: Arf !

[^]Re: Arf !

[+] [^]on se tais le troll!

[^]Re: on se tais le troll!

[^]Re: on se tais le troll!

[+] [^]Re: on se tais le troll!

[+] [^]Re: on se tais le troll!

[^]Re: Arf !

[^]Re: Arf !

[^]Re: Arf !

[^]Re: Arf !

Super ! Ca me manquait trop, le nouveau langage de la semaine...

[+] [^]Re: Super ! Ca me manquait trop, le nouveau langage de la semaine...

[^]Re: Super ! Ca me manquait trop, le nouveau langage de la semaine...

YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]List

[+] [^]Re: List

[^]Re: List

[^]Re: List

[^]Re: List

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]It's not a bug, it's a feature

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

[^]Re: YAL

y'en a vraiment qu'on rien a faire

[+] [^]Re: y'en a vraiment qu'on rien a faire

[+] [^]c du kk

[^]Re: y'en a vraiment qu'on rien a faire

[^]Re: y'en a vraiment qu'on rien a faire

[^]Re: y'en a vraiment qu'on rien a faire

[^]Re: y'en a vraiment qu'on rien a faire

Encore un autre langage...

[^]Re: Encore un autre langage...

[^]Re: Encore un autre langage...

[^]Re: Encore un autre langage...

[^]Re: Encore un autre langage...

[^]Re: Encore un autre langage...

[+] [^]Re: Encore un autre langage...

[^]Re: Encore un autre langage...

[^]Re: Encore un autre langage...

[^]Re: Encore un autre langage...

[^]Re: Encore un autre langage...

[^]Re: Encore un autre langage...