Paul TOTH a écrit :

> travail colossal ? ben c'est pas pour ça qu'on les paye ?

Non, là, le travail colossal est de sortir un truc pour .net qui a déjà
3 ans de retard. Et il faut les payer très cher pour ça !

> c'est un peu le sentiment que j'ai en fait, Borland savait faire des
> compilateurs et des IDE...sous DOS ils ont inventé Turbo Vision, sous
> Windows la VCL, c'est perfectible, mais n'empêche qu'avec la VCL
> n'importe qui peut développer une application win32 sans rien connaitre
> de l'API win32...et maintenant quoi ?! c'est pas le codefolding ou les
> génériques qui vont révolutionner Delphi, ce qu'il faut c'est justement
> un travail colossal !

Ils n'en n'ont pas pris la voie. En même temps, les generics, malgrès ce
que tu penses sont pour moi et pour beaucoup un critère de choix capital.
On en a déjà causé. Tu ne programmes pas objet. Tu n'utilises pas les
objets. Je simplifie bien sûr. Hors les environnements actuels sont
totalement objet et poussent à les manipuler. Avec delphi, c'est
préhistorique (la vcl et le runtime sont "pré-interface"). Utiliser les
objets est une plaie avec delphi, c'est pas naturel.
Il faudrait une vraie révolution côté langage en plus d'une vcl nouvelle.

>>>> A part les composants installables directement (ça marche comme ça
>>>> avec Visual), tu voudrais un truc multiplateforme. Et s'il existait
>>>> un pascal for java (qui compilerait du bytecode jvm), tu serais pas
>>>> d'accord ?
>>> ça pourrait être interressant oui
>>
>> Je ne suis pas sûr que ça plaise à Paul...
>
> pourquoi pas...mais pas un espèce de langage patché pour intégrer les
> concepts du langage Java dans Delphi, mais bien un compilateur de
> Langage Delphi qui soit capable de produire du java bytecode. S'il faut
> créer des applet ou des classes, c'est le problème du compilateur, pas
> celui du programmeur Delphi.

Je suis d'accord. L'environnement Java a quand même ses particularités
et il serait impossible je crois d'obtenir strictement la même chose
mais je ne vois pas de barrière définitive.

>> Et surtout, je ne vois pas l'intérêt d'un pascal pour jvm alors qu'il
>> y a java, qui est au point et nettement au dessus de delphi. A moins
>> que ce ne soit que pour une affaire de goût.
>
> moi j'aime pas Java en tant que langage...en temps que JVM je trouve ça
> lourd...mais si un compilateur me permet de produire un .jar à partir de
> mon projet Delphi, pourquoi pas ! Si pour atteindre ce niveau de
> portabilité il faut renoncer aux quelques appels win32 qu'on fait à côté
> de la VCL, je suis d'accord...mais si faut reprendre le projet avec des
> JForms, des JControls (comme on a connu les QForms et QControl) là je
> dis non.

Ben il y a 2 possibilités, soit une nouvelle vcl qui s'emmerde à
encapsuler swing ou awt ou une nouvelle vcl qui fait comme swt.
De toutes manières, il y aura des "dégats".
Pour 2 raisons je crois : on ne peut pas arriver à une compatibilité
parfaite et surtout, le modèle de la vcl est tellement lié aux messages
windows que je suis certain que les aficionados de la vcl diraient
"c'était mieux avant !". Car de toutes manières, il faudrait qu'elle
soit mieux écrite et mieux pensée, que ses côtés bricolage soit supprimés.
Mais une vcl actuelle et portable serait quelque chose d'intéressant,
vraiment.

> Au lieu de sortir un nouveau Delphi qui intègre les derniers effet
> visuels de Vista dont je me fou comme de l'an 40, je préfèrerais de loin
> une Delphi avec une VCL Light (TButton, TForm, TEdit...) qui reprend les
> 10% des composants utilisés dans 90% des applis et qui soit
> multiplateforme.

Mais tu es un cas à part ! Je suis sûr que plein de gens cherchent les
derniers trucs, parce que c'est "vendu" par ms et que le client s'attend
à ça.

> Quand je vois ce qu'on est obligé de faire avec Web 2.0 pour produire
> une page à peu près pratique, je suis persuadé que mon idée n'est pas
> utopique.

Web 2, je connais pas trop, mais je vois pas vraiment pourquoi certains
essaient de pousser cette technologie pour faire autre chose qu'un truc
simpliste.

Jean