Utilisateur de linux professionnellement sur des systèmes particuliers
(systèmes de mesures) et développeur occasionnel sous Windows en VB6. Le
choix du VB ne s'est pas posé car à l'époque j'avais repris le développement
de projets existants. Ensuite l'habitude s'est installée et je l'utilise
toujours.et avec satisfaction même si tout n'est pas parfait.
Maintenant, je constate que VB6 est voué à disparaître et je voudrais lui
trouver un remplaçant, voire un tout un nouvel environnement de
programmation (je peux changer de langage si nécessaire), orienté multi
plateforme (Win et Linux), performant, bien suivi, fortement utilisé et qui
existera toujours dans des années.
La technologie .Net, d'après le peu que j'en connais, ne m'attire pas. Alors
que reste-t-il ? Delphi, Real Basic, Python.. ?
"Bruno Desthuilliers" wrote in message news:45d396b5$0$17807$
Vincent Burel a écrit : > "Bruno Desthuilliers" wrote in > message news:45d36e6f$0$24957$ > >>Et comment ouvre-tu un fichier en lecture en Java ? > > > de la même manière si je veux.
Tu a l'art de sortir les questions de leur contexte, je vois.
Pas du tout, dans cet exemple on compare un appel de fonction à une utilisation de classe, c'est évident pour tout le monde que ce n'est pas une comparaison valable.
Depuis le début tu ne comprend pas ce dont je parle, il faut tout t'expliquer, tout te justifier, alors que si tu été développeur tu pigerai tout de suite. Donc tu m'en voudra pas si j'écourte la discussion... merci
"Bruno Desthuilliers" <bdesth.quelquechose@free.quelquepart.fr> wrote in
message news:45d396b5$0$17807$426a34cc@news.free.fr...
Vincent Burel a écrit :
> "Bruno Desthuilliers" <bdesth.quelquechose@free.quelquepart.fr> wrote in
> message news:45d36e6f$0$24957$426a74cc@news.free.fr...
>
>>Et comment ouvre-tu un fichier en lecture en Java ?
>
>
> de la même manière si je veux.
Tu a l'art de sortir les questions de leur contexte, je vois.
Pas du tout, dans cet exemple on compare un appel de fonction à une
utilisation de classe, c'est évident pour tout le monde que ce n'est pas une
comparaison valable.
Depuis le début tu ne comprend pas ce dont je parle, il faut tout
t'expliquer, tout te justifier, alors que si tu été développeur tu pigerai
tout de suite.
Donc tu m'en voudra pas si j'écourte la discussion...
merci
"Bruno Desthuilliers" wrote in message news:45d396b5$0$17807$
Vincent Burel a écrit : > "Bruno Desthuilliers" wrote in > message news:45d36e6f$0$24957$ > >>Et comment ouvre-tu un fichier en lecture en Java ? > > > de la même manière si je veux.
Tu a l'art de sortir les questions de leur contexte, je vois.
Pas du tout, dans cet exemple on compare un appel de fonction à une utilisation de classe, c'est évident pour tout le monde que ce n'est pas une comparaison valable.
Depuis le début tu ne comprend pas ce dont je parle, il faut tout t'expliquer, tout te justifier, alors que si tu été développeur tu pigerai tout de suite. Donc tu m'en voudra pas si j'écourte la discussion... merci
Vincent Burel
"Eric Brunel" wrote in message news:
On Tue, 13 Feb 2007 14:53:13 +0100, Christian ASTOR wrote:
1. Le temps qui coûte le plus cher n'est pas le temps d'exécution mais le temps de codage (nous coûtons toujours beaucoup plus cher que des machines...).
Certes, mais y'a un truc qui fait tout de suite peur, quant au temps de codage en Python, c'est la disparition des instructions de block au profit d'une indentation. C'est à dire que le block n'est plus défini strictement par une information explicite (accolade ou autre) mais par une information qui n'est pas forcément visible et qui n'est pas portable d'un éditeur à l'autre... Ca peut poser de sacrés problème à mon sens.
"Eric Brunel" <eric_brunel@despammed.com> wrote in message
news:op.tno33je3rqur0o@eb.pragmadev...
On Tue, 13 Feb 2007 14:53:13 +0100, Christian ASTOR
<castorix@club-internet.fr> wrote:
1. Le temps qui coûte le plus cher n'est pas le temps d'exécution mais le
temps de codage (nous coûtons toujours beaucoup plus cher que des
machines...).
Certes, mais y'a un truc qui fait tout de suite peur, quant au temps de
codage en Python, c'est la disparition des instructions de block au profit
d'une indentation. C'est à dire que le block n'est plus défini strictement
par une information explicite (accolade ou autre) mais par une information
qui n'est pas forcément visible et qui n'est pas portable d'un éditeur à
l'autre... Ca peut poser de sacrés problème à mon sens.
On Tue, 13 Feb 2007 14:53:13 +0100, Christian ASTOR wrote:
1. Le temps qui coûte le plus cher n'est pas le temps d'exécution mais le temps de codage (nous coûtons toujours beaucoup plus cher que des machines...).
Certes, mais y'a un truc qui fait tout de suite peur, quant au temps de codage en Python, c'est la disparition des instructions de block au profit d'une indentation. C'est à dire que le block n'est plus défini strictement par une information explicite (accolade ou autre) mais par une information qui n'est pas forcément visible et qui n'est pas portable d'un éditeur à l'autre... Ca peut poser de sacrés problème à mon sens.
Eric Brunel
On Thu, 15 Feb 2007 07:53:22 +0100, Vincent Burel wrote:
Certes, mais y'a un truc qui fait tout de suite peur, quant au temps de codage en Python, c'est la disparition des instructions de block au profit d'une indentation. C'est à dire que le block n'est plus défini strictement par une information explicite (accolade ou autre) mais par une information qui n'est pas forcément visible et qui n'est pas portable d'un éditeur à l'autre... Ca peut poser de sacrés problème à mon sens.
Pourquoi "pas portable d'un éditeur à l'autre"? Quel que soit l'éditeur, un espace est un espace et un tab un tab.
Et c'est une réserve que beaucoup de gens ont au départ, et qui en général disparaît très rapidement à l'usage. On finit même souvent par considérer ça comme un avantage: l'indentation reflète toujours la structure, ce qui rend le code plus lisible. -- python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
On Thu, 15 Feb 2007 07:53:22 +0100, Vincent Burel
<vincent.burel@nospam.wanadoo.fr> wrote:
Certes, mais y'a un truc qui fait tout de suite peur, quant au temps de
codage en Python, c'est la disparition des instructions de block au
profit
d'une indentation. C'est à dire que le block n'est plus défini
strictement
par une information explicite (accolade ou autre) mais par une
information
qui n'est pas forcément visible et qui n'est pas portable d'un éditeur à
l'autre... Ca peut poser de sacrés problème à mon sens.
Pourquoi "pas portable d'un éditeur à l'autre"? Quel que soit l'éditeur,
un espace est un espace et un tab un tab.
Et c'est une réserve que beaucoup de gens ont au départ, et qui en général
disparaît très rapidement à l'usage. On finit même souvent par considérer
ça comme un avantage: l'indentation reflète toujours la structure, ce qui
rend le code plus lisible.
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
On Thu, 15 Feb 2007 07:53:22 +0100, Vincent Burel wrote:
Certes, mais y'a un truc qui fait tout de suite peur, quant au temps de codage en Python, c'est la disparition des instructions de block au profit d'une indentation. C'est à dire que le block n'est plus défini strictement par une information explicite (accolade ou autre) mais par une information qui n'est pas forcément visible et qui n'est pas portable d'un éditeur à l'autre... Ca peut poser de sacrés problème à mon sens.
Pourquoi "pas portable d'un éditeur à l'autre"? Quel que soit l'éditeur, un espace est un espace et un tab un tab.
Et c'est une réserve que beaucoup de gens ont au départ, et qui en général disparaît très rapidement à l'usage. On finit même souvent par considérer ça comme un avantage: l'indentation reflète toujours la structure, ce qui rend le code plus lisible. -- python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
Ael-Rowan TERENCE
a écrit dans le message de news: On 13 fév, 14:12, "Vincent Burel" wrote:
C'est pour ça que la Nasa utilise Python, et que Ariane crashe suite à une défaillance dans un module ADA...
Mais c'est quoi ce genre d'argument ? Il manque le smiley ?
Ou alors faut-il vraiment entendre : Ariane crashe, là où, et la Nasa réussit à tous les coups ? Dans ce cas, je suis désolé, mais c'est naze comme argument.
<bruno.desthuilliers@gmail.com> a écrit dans le message de
news:1171406881.604289.275890@k78g2000cwa.googlegroups.com...
On 13 fév, 14:12, "Vincent Burel" <vincent.bu...@nospam.wanadoo.fr>
wrote:
C'est pour ça que la Nasa utilise Python, et que Ariane crashe suite à
une défaillance dans un module ADA...
Mais c'est quoi ce genre d'argument ?
Il manque le smiley ?
Ou alors faut-il vraiment entendre : Ariane crashe, là où, et la Nasa
réussit à tous les coups ?
Dans ce cas, je suis désolé, mais c'est naze comme argument.
a écrit dans le message de news: On 13 fév, 14:12, "Vincent Burel" wrote:
C'est pour ça que la Nasa utilise Python, et que Ariane crashe suite à une défaillance dans un module ADA...
Mais c'est quoi ce genre d'argument ? Il manque le smiley ?
Ou alors faut-il vraiment entendre : Ariane crashe, là où, et la Nasa réussit à tous les coups ? Dans ce cas, je suis désolé, mais c'est naze comme argument.
On Thu, 15 Feb 2007 07:53:22 +0100, Vincent Burel wrote: > Certes, mais y'a un truc qui fait tout de suite peur, quant au temps de > codage en Python, c'est la disparition des instructions de block au > profit > d'une indentation. C'est à dire que le block n'est plus défini > strictement > par une information explicite (accolade ou autre) mais par une > information > qui n'est pas forcément visible et qui n'est pas portable d'un éditeur à > l'autre... Ca peut poser de sacrés problème à mon sens.
Pourquoi "pas portable d'un éditeur à l'autre"? Quel que soit l'éditeur, un espace est un espace et un tab un tab.
Et bien sur que non, y'a des éditeurs qui peuvent transformer des tab en espace et vice versa.
Et c'est une réserve que beaucoup de gens ont au départ, et qui en général disparaît très rapidement à l'usage. On finit même souvent par considérer ça comme un avantage: l'indentation reflète toujours la structure, ce qui rend le code plus lisible.
L'indentation a toujours été un critère de lisibilité, mais laissé à la convenance du programmeur. Là c'est dangereux, parce que c'est une information implicite et relative qui influe sur le déroulement du code. D'expérience on sait très bien que c'est dangereux, sauf à travailler avec un éditeur propriétaire qui check la pertinence de l'indentation.
VB
"Eric Brunel" <eric_brunel@despammed.com> wrote in message
news:op.tnr68lldrqur0o@eb.pragmadev...
On Thu, 15 Feb 2007 07:53:22 +0100, Vincent Burel
<vincent.burel@nospam.wanadoo.fr> wrote:
> Certes, mais y'a un truc qui fait tout de suite peur, quant au temps de
> codage en Python, c'est la disparition des instructions de block au
> profit
> d'une indentation. C'est à dire que le block n'est plus défini
> strictement
> par une information explicite (accolade ou autre) mais par une
> information
> qui n'est pas forcément visible et qui n'est pas portable d'un éditeur à
> l'autre... Ca peut poser de sacrés problème à mon sens.
Pourquoi "pas portable d'un éditeur à l'autre"? Quel que soit l'éditeur,
un espace est un espace et un tab un tab.
Et bien sur que non, y'a des éditeurs qui peuvent transformer des tab en
espace et vice versa.
Et c'est une réserve que beaucoup de gens ont au départ, et qui en général
disparaît très rapidement à l'usage. On finit même souvent par considérer
ça comme un avantage: l'indentation reflète toujours la structure, ce qui
rend le code plus lisible.
L'indentation a toujours été un critère de lisibilité, mais laissé à la
convenance du programmeur.
Là c'est dangereux, parce que c'est une information implicite et relative
qui influe sur le déroulement du code. D'expérience on sait très bien que
c'est dangereux, sauf à travailler avec un éditeur propriétaire qui check la
pertinence de l'indentation.
On Thu, 15 Feb 2007 07:53:22 +0100, Vincent Burel wrote: > Certes, mais y'a un truc qui fait tout de suite peur, quant au temps de > codage en Python, c'est la disparition des instructions de block au > profit > d'une indentation. C'est à dire que le block n'est plus défini > strictement > par une information explicite (accolade ou autre) mais par une > information > qui n'est pas forcément visible et qui n'est pas portable d'un éditeur à > l'autre... Ca peut poser de sacrés problème à mon sens.
Pourquoi "pas portable d'un éditeur à l'autre"? Quel que soit l'éditeur, un espace est un espace et un tab un tab.
Et bien sur que non, y'a des éditeurs qui peuvent transformer des tab en espace et vice versa.
Et c'est une réserve que beaucoup de gens ont au départ, et qui en général disparaît très rapidement à l'usage. On finit même souvent par considérer ça comme un avantage: l'indentation reflète toujours la structure, ce qui rend le code plus lisible.
L'indentation a toujours été un critère de lisibilité, mais laissé à la convenance du programmeur. Là c'est dangereux, parce que c'est une information implicite et relative qui influe sur le déroulement du code. D'expérience on sait très bien que c'est dangereux, sauf à travailler avec un éditeur propriétaire qui check la pertinence de l'indentation.
VB
François-Xavier GENDRIN
alain a écrit :
wrote:
Vu les performances (pas compilé comme "C"), c'est bon pour faire mumuse.
D'ailleurs, professionnellement, c'est quasi-inexistant
Faut sortir, les gars. Google a récemment embauché GvR (l'auteur de Python).
Avec ça, on va aller loin... Si on veut être chomeur, oui, on peut faire du Python. Python est bien quasi-inexistant dans les grands groupes français.
ce n'est pas parcequ'il n'est pas utilisé par les grands groupes qu'il n'est pas utilisé dans des entreprises. Python reste très souple par son aspect script. Personnellement je connais deux boîtes qui utilisent du Python dont une réalisant des jeux vidéos temps réel (pas qu'en Python, mais une partie du jeu), et ils en sont très content.
alain a écrit :
bruno.desthuilliers@gmail.com wrote:
Vu les performances (pas compilé comme "C"), c'est bon pour faire
mumuse.
D'ailleurs, professionnellement, c'est quasi-inexistant
Faut sortir, les gars. Google a récemment embauché GvR (l'auteur de
Python).
Avec ça, on va aller loin...
Si on veut être chomeur, oui, on peut faire du Python.
Python est bien quasi-inexistant dans les grands groupes français.
ce n'est pas parcequ'il n'est pas utilisé par les grands groupes qu'il
n'est pas utilisé dans des entreprises. Python reste très souple par son
aspect script. Personnellement je connais deux boîtes qui utilisent du
Python dont une réalisant des jeux vidéos temps réel (pas qu'en Python,
mais une partie du jeu), et ils en sont très content.
Vu les performances (pas compilé comme "C"), c'est bon pour faire mumuse.
D'ailleurs, professionnellement, c'est quasi-inexistant
Faut sortir, les gars. Google a récemment embauché GvR (l'auteur de Python).
Avec ça, on va aller loin... Si on veut être chomeur, oui, on peut faire du Python. Python est bien quasi-inexistant dans les grands groupes français.
ce n'est pas parcequ'il n'est pas utilisé par les grands groupes qu'il n'est pas utilisé dans des entreprises. Python reste très souple par son aspect script. Personnellement je connais deux boîtes qui utilisent du Python dont une réalisant des jeux vidéos temps réel (pas qu'en Python, mais une partie du jeu), et ils en sont très content.
Eric Masson
"Vincent Burel" writes:
'Lut,
Et bien sur que non, y'a des éditeurs qui peuvent transformer des tab en espace et vice versa.
Euh, j'ai du mal à appeler un truc qui ferait ça un éditeur... Emacs, vi ou encore Eclipse ne le font pas et iirc, VStudio non plus.
L'indentation a toujours été un critère de lisibilité, mais laissé à la convenance du programmeur.
Ce qui explique le paquet de sources C indentés avec les pieds que l'on croise ici et là (j'ai des souvenirs assez épiques d'un erp dont les sources accessibles étaient soit dans un dialecte propriétaire infect, soit en C codé/indenté/testé avec les pieds). La liberté fournie par un langage type C n'est pas une mauvaise chose à partir du moment ou il est laissé entre les mains d'un développeur sachant bosser proprement, dans le cas contraire, c'est une véritable catastrophe.
Là c'est dangereux, parce que c'est une information implicite et relative qui influe sur le déroulement du code. D'expérience on sait très bien que c'est dangereux, sauf à travailler avec un éditeur propriétaire qui check la pertinence de l'indentation.
Bof, pourquoi propriétaire ? Emacs + python-mode, vim + python.vim, Eclipse + pydev ou encore VS + les extensions ironpython font un excellent travail à ce niveau.
J'ai vraiment l'impression d'un combat d'arrière garde, je n'ai rien contre le C (enfin, quand il est utilisé à bon escient), mais j'ai par contre beaucoup de mal par rapport à ce mépris des langages type Python/Perl/Ruby de la part des développeurs utilisant des langages dits "sérieux" comme Java, C, C++.
-- CJ> Les censeurs agitent plus de vent que les moulins des Pays Bas. Tiens, je savais pas que c'étaient les moulins qui créaient le vent. -+- GR in GNU : Dame qui se shoote et sang chaud pensa -+-
Et bien sur que non, y'a des éditeurs qui peuvent transformer des tab en
espace et vice versa.
Euh, j'ai du mal à appeler un truc qui ferait ça un éditeur... Emacs, vi
ou encore Eclipse ne le font pas et iirc, VStudio non plus.
L'indentation a toujours été un critère de lisibilité, mais laissé à la
convenance du programmeur.
Ce qui explique le paquet de sources C indentés avec les pieds que l'on
croise ici et là (j'ai des souvenirs assez épiques d'un erp dont les
sources accessibles étaient soit dans un dialecte propriétaire infect,
soit en C codé/indenté/testé avec les pieds). La liberté fournie par un
langage type C n'est pas une mauvaise chose à partir du moment ou il est
laissé entre les mains d'un développeur sachant bosser proprement, dans
le cas contraire, c'est une véritable catastrophe.
Là c'est dangereux, parce que c'est une information implicite et relative
qui influe sur le déroulement du code. D'expérience on sait très bien que
c'est dangereux, sauf à travailler avec un éditeur propriétaire qui check la
pertinence de l'indentation.
Bof, pourquoi propriétaire ? Emacs + python-mode, vim + python.vim,
Eclipse + pydev ou encore VS + les extensions ironpython font un
excellent travail à ce niveau.
J'ai vraiment l'impression d'un combat d'arrière garde, je n'ai rien
contre le C (enfin, quand il est utilisé à bon escient), mais j'ai par
contre beaucoup de mal par rapport à ce mépris des langages type
Python/Perl/Ruby de la part des développeurs utilisant des langages dits
"sérieux" comme Java, C, C++.
--
CJ> Les censeurs agitent plus de vent que les moulins des Pays Bas.
Tiens, je savais pas que c'étaient les moulins qui créaient le vent.
-+- GR in GNU : Dame qui se shoote et sang chaud pensa -+-
Et bien sur que non, y'a des éditeurs qui peuvent transformer des tab en espace et vice versa.
Euh, j'ai du mal à appeler un truc qui ferait ça un éditeur... Emacs, vi ou encore Eclipse ne le font pas et iirc, VStudio non plus.
L'indentation a toujours été un critère de lisibilité, mais laissé à la convenance du programmeur.
Ce qui explique le paquet de sources C indentés avec les pieds que l'on croise ici et là (j'ai des souvenirs assez épiques d'un erp dont les sources accessibles étaient soit dans un dialecte propriétaire infect, soit en C codé/indenté/testé avec les pieds). La liberté fournie par un langage type C n'est pas une mauvaise chose à partir du moment ou il est laissé entre les mains d'un développeur sachant bosser proprement, dans le cas contraire, c'est une véritable catastrophe.
Là c'est dangereux, parce que c'est une information implicite et relative qui influe sur le déroulement du code. D'expérience on sait très bien que c'est dangereux, sauf à travailler avec un éditeur propriétaire qui check la pertinence de l'indentation.
Bof, pourquoi propriétaire ? Emacs + python-mode, vim + python.vim, Eclipse + pydev ou encore VS + les extensions ironpython font un excellent travail à ce niveau.
J'ai vraiment l'impression d'un combat d'arrière garde, je n'ai rien contre le C (enfin, quand il est utilisé à bon escient), mais j'ai par contre beaucoup de mal par rapport à ce mépris des langages type Python/Perl/Ruby de la part des développeurs utilisant des langages dits "sérieux" comme Java, C, C++.
-- CJ> Les censeurs agitent plus de vent que les moulins des Pays Bas. Tiens, je savais pas que c'étaient les moulins qui créaient le vent. -+- GR in GNU : Dame qui se shoote et sang chaud pensa -+-
Vincent Burel
"Eric Masson" wrote in message news:
"Vincent Burel" writes:
J'ai vraiment l'impression d'un combat d'arrière garde, je n'ai rien contre le C (enfin, quand il est utilisé à bon escient), mais j'ai par contre beaucoup de mal par rapport à ce mépris des langages type Python/Perl/Ruby de la part des développeurs utilisant des langages dits "sérieux" comme Java, C, C++.
On aurait du en rester à la remarque d'un interlocuteur qui exprimait que le Python était un langage de script, et n'était en aucun cas comparable avec des langages de programmation tel "C" ou Java. On aurait gagner du temps.
Ceci dit, je n'ai aucun mépris pour les langages scriptés, par contre j'aimerai que ceux qui les utilisent arrètent de nous faire perdre du temps (notamment le mien) avec des prétentions imbéciles à vouloir conccurencer le "C" avec un langage scripté. Python n'est pas plus l'avenir que HTML ou c#, ce sont des langages pour des programmeurs différents, pour des développement différents, pour des résultats différents.
Sur ce, je retourne dans mon bac à sable. VB
"Eric Masson" <emss@free.fr> wrote in message
news:kb3ea4-7ve.ln1@srvbsdnanssv.oursoides-associes.com...
J'ai vraiment l'impression d'un combat d'arrière garde, je n'ai rien
contre le C (enfin, quand il est utilisé à bon escient), mais j'ai par
contre beaucoup de mal par rapport à ce mépris des langages type
Python/Perl/Ruby de la part des développeurs utilisant des langages dits
"sérieux" comme Java, C, C++.
On aurait du en rester à la remarque d'un interlocuteur qui exprimait que le
Python était un langage de script, et n'était en aucun cas comparable avec
des langages de programmation tel "C" ou Java. On aurait gagner du temps.
Ceci dit, je n'ai aucun mépris pour les langages scriptés, par contre
j'aimerai que ceux qui les utilisent arrètent de nous faire perdre du temps
(notamment le mien) avec des prétentions imbéciles à vouloir conccurencer le
"C" avec un langage scripté. Python n'est pas plus l'avenir que HTML ou c#,
ce sont des langages pour des programmeurs différents, pour des
développement différents, pour des résultats différents.
J'ai vraiment l'impression d'un combat d'arrière garde, je n'ai rien contre le C (enfin, quand il est utilisé à bon escient), mais j'ai par contre beaucoup de mal par rapport à ce mépris des langages type Python/Perl/Ruby de la part des développeurs utilisant des langages dits "sérieux" comme Java, C, C++.
On aurait du en rester à la remarque d'un interlocuteur qui exprimait que le Python était un langage de script, et n'était en aucun cas comparable avec des langages de programmation tel "C" ou Java. On aurait gagner du temps.
Ceci dit, je n'ai aucun mépris pour les langages scriptés, par contre j'aimerai que ceux qui les utilisent arrètent de nous faire perdre du temps (notamment le mien) avec des prétentions imbéciles à vouloir conccurencer le "C" avec un langage scripté. Python n'est pas plus l'avenir que HTML ou c#, ce sont des langages pour des programmeurs différents, pour des développement différents, pour des résultats différents.
Sur ce, je retourne dans mon bac à sable. VB
Lemoine
Pierre wrote:
Utilisateur de linux professionnellement sur des systèmes particuliers (systèmes de mesures) et développeur occasionnel sous Windows en VB6. Le choix du VB ne s'est pas posé car à l'époque j'avais repris le développement de projets existants. Ensuite l'habitude s'est installée et je l'utilise toujours.et avec satisfaction même si tout n'est pas parfait.
Maintenant, je constate que VB6 est voué à disparaître et je voudrais lui trouver un remplaçant, voire un tout un nouvel environnement de programmation (je peux changer de langage si nécessaire), orienté multi plateforme (Win et Linux), performant, bien suivi, fortement utilisé et qui existera toujours dans des années.
Peut-être le Pure Basic dont j'ai entendu parler: http://www.purebasic.com/french/
Pierre wrote:
Utilisateur de linux professionnellement sur des systèmes particuliers
(systèmes de mesures) et développeur occasionnel sous Windows en VB6.
Le choix du VB ne s'est pas posé car à l'époque j'avais repris le
développement de projets existants. Ensuite l'habitude s'est
installée et je l'utilise toujours.et avec satisfaction même si tout
n'est pas parfait.
Maintenant, je constate que VB6 est voué à disparaître et je voudrais
lui trouver un remplaçant, voire un tout un nouvel environnement de
programmation (je peux changer de langage si nécessaire), orienté
multi plateforme (Win et Linux), performant, bien suivi, fortement
utilisé et qui existera toujours dans des années.
Peut-être le Pure Basic dont j'ai entendu parler:
http://www.purebasic.com/french/
Utilisateur de linux professionnellement sur des systèmes particuliers (systèmes de mesures) et développeur occasionnel sous Windows en VB6. Le choix du VB ne s'est pas posé car à l'époque j'avais repris le développement de projets existants. Ensuite l'habitude s'est installée et je l'utilise toujours.et avec satisfaction même si tout n'est pas parfait.
Maintenant, je constate que VB6 est voué à disparaître et je voudrais lui trouver un remplaçant, voire un tout un nouvel environnement de programmation (je peux changer de langage si nécessaire), orienté multi plateforme (Win et Linux), performant, bien suivi, fortement utilisé et qui existera toujours dans des années.
Peut-être le Pure Basic dont j'ai entendu parler: http://www.purebasic.com/french/
