Discussion :

[yoyo88]

Non, VB.NET est condamné à une mort lente, il suffit de voir chez Microsoft, qui met beaucoup plus en valeur C# que VB.NET dans ses produits et les interfaces de développement.

Sachant qu'on peut faire strictement la même chose en VB.NET et en C#, a mon avis c'est plus un problème commercial, d'ailleurs si on regarde le tableau on se rend compte qu'il y a beaucoup plus de développeur dans les langage tel que C,C++ et Java langage plus ou moins proche de C#.

quand tu regarde coté Basic, y'a quoi comme marcher ou Microsoft peut piquer des développeur ?

bref VB.NET est pas prêt de mourir, c'est juste que commercialement il est plus intéressant de promouvoir le C#.

[FailMan]

bref VB.NET est pas prêt de mourir, c'est juste que commercialement il est plus intéressant de promouvoir le C#.

Non certes il ne mourra pas demain, mais C# évolue, tandis que VB semble être assez figé (c'est une impression que j'ai). Reste à savoir jusque quand Microsoft continuera de faire évoluer VB en même temps que C#.

Personnellement ça me ferait mal au derrière que VB disparaisse, j'ai appris à coder avec ce langage qui est assez simple d'accès, c'est peut-être à cause de sa simplicité qu'il n'a pas autant de succès.

[yoyo88]

Non certes il ne mourra pas demain, mais C# évolue, tandis que VB semble être assez figé (c'est une impression que j'ai). Reste à savoir jusque quand Microsoft continuera de faire évoluer VB en même temps que C#.

Non je peut t'assurer que VB évolue aussi, d'ailleurs les Evolution de C# ont leurs équivalent en VB, En plus, sachant que les principal évolution se joue surtout au niveau du framework .NET. y'a pas de raison de crainte une disparition de VB.

Personnellement ça me ferait mal au derrière que VB disparaisse, j'ai appris à coder avec ce langage qui est assez simple d'accès, c'est peut-être à cause de sa simplicité qu'il n'a pas autant de succès.

Non je pense pas, je pense que c'est plus une question de background des développeur. il est beaucoup plus facile de convaincre un dev JAVA de passé a .NET via C# que via VB.NET alors qu'au final sa reviens quasiment au même.

[el_slapper]

(.../...)Non je pense pas, je pense que c'est plus une question de background des développeur. il est beaucoup plus facile de convaincre un dev JAVA de passé a .NET via C# que via VB.NET alors qu'au final sa reviens quasiment au même.

+1, et c'est sans doute aussi vrai pour d'autres langages à syntaxe légère, tels que C ou C++.

Inversement, quelqu'un comme moi qui vient de langages verbeux(Cobol et VBA), entre beaucoup plus facilement dans VB.NET que dans C#. Même si j'ai été amené à faire de ce dernier(je suis pas raciste), instinctivement, je me retrouve plus facilement dans VB.NET.

[SurferIX]

Hmm, complètement faux.

La question qui me viendrait à l'esprit serait plutôt :

"Qu'est ce qu'on ne peut pas faire avec C ?"

Développer de grosses applications Internet, en équipe, et (surtout) rapidement.

Python est un langage médiocre en tout point (pas de récursion terminale, pas de fonction de premier ordre, très mauvaise compatibilité descendante etc.)

Il est juste tout simplement excellent en certains points que d'autres langages ne pourront jamais se targuer. Pour avoir développé en C, en Php, en Pascal Objet (Delphi), en C++, en ADA et en JavaScript, franchement, Python est excellent sur tous les points qu'on aime lorsqu'on veut développer vite, pour peu qu'on soit strict (comme Php) sinon on peut faire des merdes immondes (comme Php). Mais le langage en lui même est super génial. Rien que le truc qui me manque dès que je replonge en C ou en Php: l'assignation multiple, par exemple quelque chose qui n'existe pas mais sur le principe, je le fais très souvent, et c'est super compréhensible (= maintenable) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

(x0,y0,x1,y1) = screen.get_bounds()

... => fais moi ça dans un autre langage et aussi clairement

De plus j'ai passé plusieurs heures à traduire un article ici, me dis pas que j'ai fait ça pour rien :

Débutants : pourquoi le langage Python ?

--
Olivier

[spidermario]

Rien que le truc qui me manque dès que je replonge en C ou en Php: l'assignation multiple, par exemple quelque chose qui n'existe pas mais sur le principe, je le fais très souvent, et c'est super compréhensible (= maintenable) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

(x0,y0,x1,y1) = screen.get_bounds()

... => fais moi ça dans un autre langage et aussi clairement

D’autres langages ont un pattern matching (ou « filtrage de motif ») plus poussé encore.

Je ne sais pas si tu connais les types algébriques, mais en Haskell, par exemple, une valeur de type “Maybe a” peut valoir soit “Nothing”, soit “Just (une valeur de type a)”.

La fonction “find” du module Data.List, par exemple, renvoie, appliquée à une fonction de type « a -> Bool » et à une liste de « a » (ce type est noté « [a] »), un “Maybe a”.

Eh bien, il est tout-à-fait possible, si l’on est sûr que la liste contient un élément qui vérifie le prédicat, d’écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Just x = find (> 10) [1, 8, 12, 5]

Et x vaut 12.

[SurferIX]

D’autres langages ont un pattern matching (ou « filtrage de motif ») plus poussé encore.

Je ne sais pas si tu connais les types algébriques, mais en Haskell, par exemple, une valeur de type “Maybe a” peut valoir soit “Nothing”, soit “Just (une valeur de type a)”.

La fonction “find” du module Data.List, par exemple, renvoie, appliquée à une fonction de type « a -> Bool » et à une liste de « a » (ce type est noté « [a] »), un “Maybe a”.

Eh bien, il est tout-à-fait possible, si l’on est sûr que la liste contient un élément qui vérifie le prédicat, d’écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Just x = find (> 10) [1, 8, 12, 5]

Et x vaut 12.

On peut faire pareil avec les fonctions non nommées = lambda :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
>>> print filter(lambda x: x % 3 == 0, [2, 18, 9, 22, 17, 24, 8, 12, 27])
[18, 9, 24, 12, 27]

Mais je n'ai jamais dit que d'autres langages n'étaient pas "bons", j'ai juste dit, peut-être que je me suis mal exprimé, que je trouvais que dire que "python était un langage médiocre" était un peu fort, surtout lorsque dans le même post tu le compare à d'autres langages.
D'autres trucs super pratiques en python :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if 10<x<20: blabla

Les fonctions intégrées directement aux classes qui leur donne la possibilité de "customiser" la mise à plat de l'objet de la classe, etc. et pour revenir aux multiples assignations :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

for (x,y) in tableau_coordonnees: blabla

Bref, je trouve juste que c'est loin d'être un langage médiocre. Son seul défaut majeur à mon sens et qu'il est bien trop permissif et pas de membre private. Enfin pas de vrais private/public.

..

[unknow0]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

(x0,y0,x1,y1) = screen.get_bounds()

... => fais moi ça dans un autre langage et aussi clairement

en perl exactement de la meme maniere :p

[SurferIX]

en perl exactement de la meme maniere :p

Voir mon article ici : Débutants : pourquoi le langage Python ?

Le monsieur est "à peine" le créateur de fetchmail, et connait très bien une douzaine de langages. En résumé, "oui", perl fait pareil, mais est tellement lourd sur plein d'autres points qu'il ne tient absolument pas la route face à python

[spidermario]

On peut faire pareil avec les fonctions non nommées = lambda :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
>>> print filter(lambda x: x % 3 == 0, [2, 18, 9, 22, 17, 24, 8, 12, 27])
[18, 9, 24, 12, 27]

Ce n’est pas précisément le point que je voulais montrer.

Je voulais juste montrer qu’en Haskell, la déstructuration n’était pas limitée aux tuples, listes, etc.
Un autre exemple, qui sera peut-être plus parlant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
data Point = Point
    {
        x :: Integer,
        y :: Integer
    }

Point { x = xFin, y = yFin } = positionFin

« xFin » et « yFin » sont alors définis comme les attributs « x » et « y » de « positionFin ».

PS : il est amusant de constater les ressemblances occasionnelles entre Haskell et Python : l’exemple que tu as donné s’écrirait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
print (filter (\x -> x `mod` 3 == 0) [2, 18, 9, 22, 17, 24, 8, 12, 27])

-- ou :
print $ filter (\x -> x `mod` 3 == 0) [2, 18, 9, 22, 17, 24, 8, 12, 27]

-- ou encore, avec la composition de fonctions :
print $ filter ((== 0) . (`mod` 3)) [2, 18, 9, 22, 17, 24, 8, 12, 27]

[souviron34]

Développer de grosses applications Internet, en équipe, et (surtout) rapidement.

Je me marre

Tout est question de bibliothèque...

... => fais moi ça dans un autre langage et aussi clairement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
xo = XHeightOfScreen
y0 = XWidthOfScreen

en X11, en C

[Camille_B]

Mais je n'ai jamais dit que d'autres langages n'étaient pas "bons", j'ai juste dit, peut-être que je me suis mal exprimé, que je trouvais que dire que "python était un langage médiocre" était un peu fort

Je me répète pour la deuxième fois, j'ai déjà dis que mes propos étaient largement exagérés et faux. Une discussion s'en est suivie.

Relire la discussion plutôt que de citer la phrase polémique inutilement.

P.S. : et dire que Perl est en tout point plus lourd que Python est tout aussi erroné, c'est mal connaître les pratiques "modernes" de coder en Perl, très mal.

[Florian Goo]

Personnellement, LE truc qui me gène avec Python, c'est le typage dynamique.

Je ne comprends pas comment un programmeur digne de ce nom (comprendre autre qu'occasionnel) peut préférer un système de typage dynamique à un système statique (c'est une réelle incompréhension, pas une façon de dire que vous êtes de mauvais programmeurs).
Là où vous voyez un confort, je vois une insécurité énorme. Ce système de typage reporte à l'exécution des erreurs qui se seraient vues à la compilation avec un typage statique.
Pour moi, un typage dynamique, c'est carrément éliminatoire pour un langage de programmation.

Vraiment, je ne comprends pas. Et quand je vois autant de monde clamer que Python est un langage formidable, je me dis que je dois rater quelque chose.

[gl]

Personnellement, LE truc qui me gène avec Python, c'est le typage dynamique.

Je ne comprends pas comment un programmeur digne de ce nom (comprendre autre qu'occasionnel) peut préférer un système de typage dynamique à un système statique (c'est une réelle incompréhension, pas une façon de dire que vous êtes de mauvais programmeurs).
Là où vous voyez un confort, je vois une insécurité énorme. Ce système de typage reporte à l'exécution des erreurs qui se seraient vues à la compilation avec un typage statique.
Pour moi, un typage dynamique, c'est carrément éliminatoire pour un langage de programmation.

Ca va au delà du typage dynamique, ama. C'est le choix de la vérification au runtime vs à la compilation (le typage n'étant qu'une petite partie).

Les outils d'analyse de code (pylint pour Python par exemple) permettent d'attraper une partie des problèmes mais pas tous.

Sinon, cette vérification au runtime est effectivement un point "noir" des langages "dynamiques". La contrepartie est de permettre de tester vite fait un truc.

Personnellement c'est une des raisons pour lesquels je cantonne ce type de langage (Python essentiellement mais il m'est aussi eu arrivé de faire un peu de Perl, des scripts shell, du sed, etc.) à quelques tâches particulières où je n'ai pas besoin d'une robustesse à toute épreuve et où la mise au point via essai au runtime est suffisamment simple et rapide (en gros petit script pour me faciliter la vie mais qui n'a pas vocation à partir en prod, scripts de test, complément à un autre langage pour permettre une modification du comportement par l'utilisateur, prototype rapide, etc.)

[Florian Goo]

Personnellement c'est une des raisons pour lesquels je cantonne ce type de langage […] à quelques tâches particulières où je n'ai pas besoin d'une robustesse à toute épreuve et où la mise au point via essai au runtime est suffisamment simple et rapide.

Je pense très exactement la même chose que toi. Python et consort, c'est bon pour du faire du script (comme tu dis, des petites bricoles vite faites, des prototypes ou une API pour un gros projet). Ces langages ont parfaitement leurs raisons d'être.

Mais quand je vois des projets de grande (ou même moyenne) ampleur écrits 100% en Python, ça me laisse réellement perplexe.

[Camille_B]

Cela relève du préjugé. Nombreux sont les gros projets écrits avec des langages dynamiques qui sont propres et solides.

D'ailleurs il est inutile d'en citer tellement ils sont nombreux et omniprésents.

La manière de programmer est différente, c'est tout.

[Uther]

C'est bien ce que l'on dit, ce n'est pas impossible mais il faut faire attention à beaucoup plus de choses pour éviter les bêtises, et le risque de problème grossit avec la taille du projet.

Souvent on en revient a se forcer a faire comme si le typage était statique : autant utiliser un vrai typage statique.

[remi_inconnu]

Mais quand je vois des projets de grande (ou même moyenne) ampleur écrits 100% en Python, ça me laisse réellement perplexe.

Le fait que cela soit un langage typé dynamiquement impose de faire plus attention à ce que tu écris, mais il ne faut cependant pas oublier que quand tu écris un projet, et cela quelque soit le langage, ce qui fait sa robustesse, ce n'est absolument pas le langage de programmation mais plutôt le test et la manière d'architecturer ton appli. On peut faire de grosse daube dans un langage fortement typé (j'ai eu quelques expériences de ce type avec le C++). Dès que tu écris une ligne de code, si tu veux être absolument sûr, il faut qu'elle soit couverte par un test case, sinon tu ne peux en garantir l'intégrité, même pour les fonctions d'une ligne de code.
Et puis le typage fort n'a jamais empêché de faire des cast, voir utiliser les void *...

[gl]

Le fait que cela soit un langage typé dynamiquement impose de faire plus attention à ce que tu écris

...

Et puis le typage fort n'a jamais empêché de faire des cast, voir utiliser les void *...

Juste une remarque : typage fort n'est pas le contraire de typage dynamique. Ce sont juste deux notions différentes (dynamique vs statique dans un cas, fort vs faible dans l'autre cas. Sachant bien entendu que dans les deux cas ce n'est pa tout noir ou tout blanc).

[anthyme]

Je suis plutôt d'accord avec vous.
Après une application web très orienté "données" peut être fait très élégamment et maintenable avec du python et un Framework Web comme django.
Il faut juste ne pas avoir des contrôleurs avec des méthodes qui font des dizaines de lignes.