GoldenCrystal
: Kevin > Nan mais si tu penses à VB6... C'est lent uniquement parce que c'est fait sur une base m*rdique. Si ça se trouve VB.NET est plus rapide que VB6 (et de mémoire, en ayant vu la tronche de l'ASM x86 généré pour les deux, c'est fort possible).

Le VB.NET, ce n'est plus du VB.
Le vrai VB, c'est VB1-VB6. Ils ont tout changé dans VB.NET, la compatibilité est presque inexistante. Alors qu'entre VB4, VB5 et VB6, le code s'échange assez facilement dans les 2 sens.

3. Pourquoi VB ? C#, ça powa carrément plus...

Mais je ne sais pas programmer en C#, et le langage est beaucoup plus complexe que le VB (quoique parfois...)

Le VB est très complexe. Regarde le genre de trucs qui sont censés fonctionner en VB:
123+"456" -> 579
123&"456" -> "123456"
"456"+123 -> "456123"
"456"&123 -> "456123"
0+"456"+"123" -> 579
0+("456"+"123") -> 456123
CLng("456")+123 -> 579
CLng("456")+"123" -> 579
"123"+CLng("456") -> "123456"
...
La conversion automatique des types est très complexe. C'est une des raisons fondamentales de la lenteur du VB. Et contrairement au C, les règles de promotion ne sont pas symétriques: c'est la première opérande qui décide le type du résultat, pas celle de type le plus large.

et pour les librairies (il en faudra, c'est certain), je ne sais pas si je transformerai le pseudo-assembleur en bytecode (ça permettrait éventuellement certaines optimisations pour le 'linking') ou si je compilerai nativement, tout en gardant les infos de type (faut pouvoir utiliser la librairie après)

Linke le programme statiquement quand tu es encore en ta représentation intermédiaire, et convertis le tout en natif une fois le linking terminé.