Version imprimable
t'a bu, t'est miro ou quoi ?Citation:
Envoyé par ulysse31
1-mono fonctionne sous linux!
2-vb.net est plus contraignant que C# (dim a chaque fois, end ..., le gros mot "GOTO", et le type "sale' : "Variant")
3- tu trouve que C++ ou delphi est "ouvert" ?
Citation:
Envoyé par Édit
Bonjour DoccpuCitation:
t'a bu, t'est miro ou quoi ?
1-mono fonctionne sous linux!
2-vb.net est plus contraignant que C# (dim a chaque fois, end ..., le gros mot "GOTO", et le type "sale' : "Variant")
3- tu trouve que C++ ou delphi est "ouvert" ?
je ne veux pas troller et j'apporte un avis sur le topic. Par contre, je voudrais pas que cela tourne comme au début des avis avec Maniak et Moonheart dont le premier etait particulierement agressif ce qui ne fait pas avancer le debat. Donc je ne suis pas Miro et je n'ai pas bu (sans me mouiller surement moins que toi vu que je n'aime pas l'acool) et un peu de respect stp.
Pour repondre a tes propos
1)Mono fontionne sous Linux : oui je sais et je l'ai essayé sous tux dans ses débuts mais on ne peut pas tous faire et cela reste un travail ardue pour porter un truc proprietaire MS sous un systeme Libre respectant des standard posix
2)Delphi n'est pas "ouvert" mais fait preuve d'ouverture en permettant un developpement sous la plate forme de son choix
3)le C++ est un langage standard comme le C (en respectant la norme ANSI). Tu le prend et tu compiles sous win (avec wxwindows st ou gtk si tu utilises des formes) ou sous tux et ca roule. C'est ce que j'appelle être "ouvert", tout du moins bien plus que .Net, bien sur cela reste mon avis uniquement ce qui etait le but premier de mon propos.
Pour faire suite aussi a un de tes messages precedant comme quoi vbnet fait moins professionnel c'est une vue restreinte a ton ideal. J'ai cru pour 'un miro' comprendre que tout etait traduit dans l'IL, alors vbnet ou C# quelle difference pourvu que chacun y trouve son compte.
Mmh ? Qu'est-ce que je viens faire là-dedans ? :)Citation:
Envoyé par ulysse31
Et je ne me souviens pas avoir été "particulièrement agressif".
Particulièrement dur avec l'héritage de VB6 par contre, ça oui :)
C'est pas sur du MSIL qu'on bosse, mais sur le langage choisi. C'est là qu'il peut y avoir des complications :)Citation:
Envoyé par ulysse31
Maintenant l'important c'est que les projets soient faits, fonctionnent et que le client soit content, dans la durée. Le reste est accessoire.
Sinon un petit détail :VB.NET n'est plus contraignant que C# que si on fait du VB.NET 'propre' (Option Explicit+Strict, Try/Finally pour tous les objets implémentant IDisposable, ce genre de choses).Citation:
Envoyé par doccpu
Je ne suis juste pas sûr que ça corresponde à la majorité des développeurs VB.NET. Mais il y en a, ça je n'en doute pas, et on peut faire du code tout aussi crade en C#, Delphi ou n'importe quel autre langage. C'est peut-être juste plus facile/tentant en VB :)
Je ne comptais pas troller non plus mais t'a mal pris ma boutade domage ulysse. au fait coment vas penelope ? :wink: :lol:
Je ne consoit pas de faire du code "sale" (autant que possible) car qui dit code sale dit mauvaise lecture ce qui entraine a dire mauvaise maintenance ! Maintenant si tu comte juste faire un code qui t'afiche bonjour sur un click de bouton tu le fais un peu comme tu veux ....Citation:
Envoyé par Maniak
On est d'accord. Maintenant, je peux te sortir des trouzaines d'exemples de 'gens' (je ne peux pas les qualifier de développeurs, même s'ils sont payés pour ça) que ça ne gêne absolument pas. Ça leur simplifie la vie, peu importe si ça complique les choses plus tard. C'est plus tard.Citation:
Envoyé par doccpu
Et je crains d'avoir croisé beaucoup plus de 'gens' avec cette approche que de dévs qui se préoccupent vraiment de la qualité de leur code.
Ça, c'est un problème de plus haut niveau que le choix du langage. Quoi qu'on choisisse, le langage seul ne suffit pas à obtenir du bon code ou une espèce de bouillie inutilisable. On peut faire du très bon et du très mauvais code avec n'importe quel langage. Là où on peut commencer à faire des distinctions, c'est si tel ou tel langage a plus ou moins de barrières pour pousser les développeurs à faire du code de qualité.
Le fait que VB.NET permette de s'affranchir du typage et des déclarations de variables et surtout le fait que ce soit essentiellement utilisé par fainéantise (et/ou incompétence) du développeur, c'est ce que j'ai principalement contre ce langage.
Au final, ce n'est pas tellement le langage qui me gêne (les préférences syntaxiques sont purement subjectives, c'est uniquement matière à troll, je vais éviter ça pour ce post :), mais ceux qui utilisent les libertés qu'il permet pour se simplifier la vie et compliquer celle des autres.
Donc à choisir, quand il y a des doutes sur le sérieux et/ou les capacités des dévs, autant prendre un langage qui permet moins de 'simplifications' de ce genre. Ou former les dévs pour qu'ils n'en abusent pas, en espérant qu'ils écouteront. Partant de là, le choix du langage importe peu :)
Si je me retrouve à devoir maintenir une appli dont le code a été bien fait, que ce soit du VB.NET ou du C#, aucune importance, je serai aux anges.
Si c'est une appli faite par un branleur incompétent, VB.NET ou C#, j'aurai envie de me pendre. Mais au moins si c'est du C#, je n'aurai pas à me taper les problèmes supplémentaires causés par l'absence de déclarations et de typage quand celui qui a pondu le code aurait mieux fait de se casser une jambe le jour de son entretien d'embauche :)
J'ai effectivement trouvé un site qui teste différentes techno .net pour les mêmes programmes et qui trouve des différences (au niveau math et I/O) !Citation:
quelques différences de performances sont visibles mais rares
Benchmarking Math & File I/O
Résultat pour les tests effectués (il en manque je suis d'accord) : C# va plus vite...
Moi qui croyais que tous les programmes .net donnaient le même code intermédiaire... :?
Allez c'est reparti :roll:Citation:
Envoyé par verre d'eau
Comme quoi les gens voient ce qu'il veulent bien voir...
Ce benchmark est justement la confirmation que je cite :
Si tu regarde un peu plus attentivement tu verra que le C# et le VB ont exactement les mêmes performance sauf sur les I/O. L'un est un cheveux plus rapide sur les int et l'autre un poil plus rapide sur les long (certainement des imprécisions de mesures).Citation:
tous les programmes .net donnaient le même code intermédiaire...
Et pour la différence sur les I/O pas de grand mystère y 'a qu'a regarder les sources des benchs :Citation:
Visual C# 9.7 23.9 17.7 4.1 9.9 65.3
Visual Basic 9.8 23.7 17.7 4.1 30.7 85.9
Code:
2
3
4
5
6
Et oui l'exemple C# utilise la classe I/O native de .net alors que l'auteur du bench a fait le choix discutable :? d'utiliser les fonctions de fichiers de compatibilité VB6.Code:
2
3
4
5
6
Si tu as du temps a perdre tu peux recompiler l'exemple C# avec FileOpen (en ajoutant une ref à la MicrosoftVisualBasicgnagna.dll) ou plus simplement en utilisant dans VB.NET l'objet streamWriter (chose qui aurait du être fait par l'auteur du bench si il avait été sérieux).
A+
Tout à fait d'accord avec Kikos31 si on utilise pas les mêmes classes on aura pas les mêmes perfs ça c'est sur ;)
Mais bon je crois qu'on ne peux pas sérieusement choisir tel ou tel langage pour des raisons de performances car justement les différences de perf se feront plutôt au niveau du code créé ("propre" ou pas) qu'au niveau du langage ;)
J'ai quand même constaté quelque chouillas de différences entre 2 codes identiques C# et vb.net mais faudrait aussi regarder les options de compilation par défaut de VS.NET qui diffèrent selon le langage utilisé ;)
ouf !!
Me voici soulagée !
Merci
Salut tous le monde;
Étant nouveau sur developpez.net, je voulais repondre dans le débat “quel language préférez-vous pour le développement web” mais j'ai pas l'autorisation 8O en faite ma réponse est sans hésitation ASP.NET (C#) mais je me retrouve obligé mal heureusement d'utilisé PHP, et voila ma problématique
Je travail sur une référence bibliographique XML-basé, et je suis obligé de faire une double transformation vu les possibilités limitée de XSLT, donc une deuxième transformation est obligé mais là j'ai grand problème car je doit appelée un objet par espace de nom et une méthode de cette objet pour chaque élément du fichier Xml
Exemple
voici un fichier
<!--Déclarations des espaces de noms des DTD et... -->
<PolyCop Name="Introduction en Odontologie-Concervatrice">
<Paragraphe>
L'OC est une <Lien Vers="...">décipline</Lien>...
</Paragraphe>
<!-- Jusque là des balises que je peut transformer en XSLT -->
<Math:Graphe ... />
<!-- Je ne peut pas déssiner un graphique en XSLT -->
</PolyCop>
Donc je doit déssiner le graphe à l'aide d'un language Web dynamique
Vue qu'il y a environ 200 elements pour débuter, je ne vais pas m'amuser a faire
switch(espacedenom){
case "Math":
// ... un autre switch pour les methode de chaque objet
break;
je veut créer ces objets et appelé leur méthodes dynamiques comme je peut faire en Php
$objet->$nomDeLaMethod($tableauDesAttribue);
Si ce n'est pas possible en C#, ce côté Hyper-dynamique du polymorphisme Php doit être plus ilucidé dans la comparaison des languages car ma solution deviens hyper irréalisable si j'utilise des fichiers DLL externe
Je crois surtout que dans 90% des projets, utiliser tel ou tel langage ne change pas grand chose, surtout sur cette plateforme qu'est Dot Net.
Sur quoi se base le choix d'un langage ? Eh bien, surtout sur la culture de la boite; le coût; la portabilité ... Les performances venant bien après.
A part sur des projets industriels et très lourd (où la ben C/C++ a la grosse part du gâteau), difficile de trancher objectivement.
Dire tel langage est mieux que celui-là (perso, c'est c++ ) est bien prétentieux et surtout personnel.
L'histoire du "VB c'est pour ceux qui savent pas programmer" est à mon avis faux. Tout repose sur le programmeur lui-même, on peut utiliser aussi des GOTO en C et variant existe ailleurs que dans VB.
La seule différence est que VB tolère plus facilement le mauvais codage avec une profusion de possibilités un peu limites, faut bien le dire, mais qui oblige à les utiliser? Personne.
On peut très bien faire une architecture de classes (avec VB.NET) tout à fait digne d'un javaman, seulement il faut se faire violence car VB.NET ne l'impose pas (en java ou C++ essaie toujours héhé ... ).
Sur VB, l'énorme reproche que je lui fait est la non-compatibilité entre les versions (l'arrêt des up de VB6 cause un sacré bazar ... ), en fait, plus la politique menée que le langage lui-même.
Sur C sharp, malgré tout le tapage fait par microsoft (mm dans le bouquin de Visual c++ lol) en faveur de leur bb, je suis assez suspicieux sur l'avenir de ce langage. La sauce ne prend pas facilement et hormis quelques projets, j'avoue que je ne vois pas grand chose en C# actuellement.
J'ai voté VB.Net (sur DOT NET je précise), il permet de concevoir des projets rapidemment, de façon efficace.
Je ne vois pas l'intérêt de s'embêter avec les MFC (visual C++) - toujours pour les 90% de petits projets je précise-
C# me semble plus commercial que réellement utile actuellement.
Delphi, je ne connais pas.
J'ai programmé avec Vb, VB.NET et C#
Je préfère le C#, principalement pour la lisibilité du code, ce dernier est en effet moins verbeux que VB.NET et plus "clair" à la lecture.
C# a également quelques *petits* avantages : documentation générée, quelques automations avec VS.NET (les /// ). Il est également insensible à la casse ... ce qui quelque part oblige à faire attention aux noms de variables, et c'est pas plus mal ;) !
Seulement, alors que Vb est très immonde, VB.NET n'est juste qu'une traduction litterale du C# ... il y a quelques différences, mais globalement les deux langages sont aussi puissants, ils reposent sur les memes concepts et les memes librairies... Il n'y a donc pour moi aucune différence technique ... le choix ne peut finalement se porter que sur les préférences du\des programmeurs. (venant de java, on penchera surement vers C# alors que les ex-VB viendront plus facilement vers VB.NET ... finalement, ce n'est surement qu'une technique marketing pour attirer le plus de monde à utiliser la technologie .NET !)
Juste la fainéantise de certains. Mais ils sont nombreux, et sont dans les plus rapides à sortir une panoplie d'arguments bidons pour défendre leur choix :)Citation:
Envoyé par Kaktus
Yup. C'est juste dommage de devoir "se faire violence". C'est tellement plus reposant d'être rappelé à l'ordre automatiquement pour la plupart des choses :)Citation:
Envoyé par Kaktus
On n'a pas vu les mêmes choses alors. Parce que dans ce que j'ai vu jusque-là, c'est essentiellement du C#, avec VB.NET utilisé essentiellement par ceux qui viennent de VB6 et qui préfèrent jouer la sécurité en restant dans une syntaxe familière. Ainsi que les quelques rares âmes égarées qui connaissent aussi bien la syntaxe VB et la syntaxe C, et qui préfèrent la première :)Citation:
Envoyé par Kaktus
Sans compter tous les branleurs en puissance qui préfèrent VB.NET parce que ça leur permet de ne pas se compliquer la vie avec des choses aussi inutiles que le typage et la déclaration des variables :)
Ho !!! ça va oui !?Citation:
Envoyé par Maniak
il y a aussi des gens qui codent en VB.NET de manière très propre et professionnelle !
Lis mieux avant de t'emballer :)Citation:
Envoyé par Yorglaa
Où tu vois que j'ai dit que tous les devs VB sont des branleurs en puissance ?
Maintenant, si tu veux dire qu'on peut faire du VB.NET de manière très propre et professionnelle en s'affranchissant du typage et de la déclaration des variables, là on ne va pas être d'accord.
Il y a des langages non-typés avec qui ça marche très bien (du moins le non-typage. la non-déclaration des variables c'est autre chose). VB.NET n'est pas un langage non-typé. C'est un langage typé qui a une option pour *masquer* les types et faire des conversions dans tous les sens selon ce que le compilo/runtime juge nécessaire. Rien à voir. Et je vois mal comment on peut faire quelque chose très propre et professionnel de cette façon.
On ne va même pas parler de la non-déclaration de variables, qui est particulièrement crade à la base. Donc pour en faire quelque chose de propre, c'est pas gagné.
Enfin... pour une appli de 10 lignes je suppose que c'est jouable :)
PS: au passage, si le C# avait des équivalents à Option Explicit/Strict, j'aurais tout autant de critiques à son encontre. Et encore plus à l'encontre de ceux qui utilisent ces "possibilités". C'est loin d'être une croisade contre le VB :)
Ok, ok je me suis emballé... désolé :oops: !
Mais étant personnellement DBA Oracle avant d'être développeur en VB.NET, j'ai l'habitude du PL/SQL...
Or avec cette habitude, il est (pour moi) EXCLU de ne pas déclarer mes variables, de ne pas typer correctement ou de laisser le système faire du trans-typage... ne serait-ce que pour des questions de performances (le trans-typage TUE les perfs en bases de données)...
D'où ma réaction un peu épidermique...
Une fois encore, excuse-moi de cette envolée bien rapide et au combien maladroite !
Pas de problème, ça arrive :)
Pi au final on est d'accord, c'est encore mieux :)
Cela dit, SmallTalk, Python et Ruby sont très 'libres' au niveau des types de variables, et ils se portent très bien comme ça. Comme quoi un langage prévu pour fonctionner de cette façon peut être très bien.
Le problème de VB.NET n'est pas tellement qu'on peut faire du code sans typage. C'est que l'absence de typage n'est pas un des fondements du langage. C'est juste une facilité pour programmeurs débutants ou fainéants. Il y a toujours du typage derrière, c'est juste une couche de bidouillage par dessus. Et c'est un peu pour ça que ça pose des problèmes.
Moralité : pour ceux qui n'aiment pas devoir tout typer, utilisez les langages appropriés à ce genre d'utilisation. VB.NET en a peut-être l'apparence, mais il n'en fait pas partie.
Ensuite, à partir du moment où *toute* appli VB.NET est en Option Explicit et Option Strict activés, la différence avec C# est essentiellement syntaxique, donc globalement mineure.
ok pour l'option Explicit je vois bien.
Mais l'option Strict quel est son avantage ?
par exemple, dans une propriété de composant, devoir affecter "boolean.TrueString" au lieu de "True" n'ajoute rien (à mon sens) à la lisibilité pour quelqu'un qui devrait reprendre mon code...
autant j'aime les règles qui "obligent" à respecter une certaine propreté, autant pousser le bouchon trop loin n'est plus très utile (toujours à mon sens)...
mais j'ai peut-être mal capté l'utilité du paramètre Strict...
Ben le typage :)Citation:
Envoyé par Yorglaa
C'est quoi TrueString ? :)Citation:
Envoyé par Yorglaa
Strict On sert surtout à éviter de faire des toto = 0 quand toto est booléen, ou à récupérer une chaîne et s'en servir pour faire des additions avec des entiers (ou pire, des flottants), sans aucun contrôle de validité.
Avec Strict Off, pas besoin d'indiquer les types de variables, pas besoin de caster, toutes les conversions se font automatiquement.
Et VB.NET, comme dit plus haut, n'est pas un language conçu autour du non-typage. C'est juste un déguisement. Et les effets secondaires ont une fâcheuse tendance à causer des bugs très lourds à trouver. Et à rendre le code tout sauf clair.
Dans le cadre d'une librairie, on n'en parle même pas.
Exemple bidon : tu fais un projet en C# qui tape dans une librairie VB.NET. Dans le projet VB, tu veux utiliser une méthode censée renvoyer un entier. Manque de bol, en fait elle renvoit un Object parce que le type de retour n'a pas été indiqué, merci Option Strict On. C'est vrai après tout, pourquoi est-ce que le dév de la librairie se serait fatigué à mettre des types et à valider ses données si tout peut se faire automatiquement ?
Sauf que du coup, c'est toi qui doit recevoir un Object, le valider, le convertir en Int32 si ça marche, gérer les erreurs si ça ne colle pas, et *ensuite* faire ce que tu voulais faire avec au départ.
C'est valable pour les librairies, mais ça l'est aussi pour un seul projet, fait par un autre dév et que tu dois reprendre. Réutiliser des méthodes dont tu n'est pas bien sûr des types de données renvoyés, qui peuvent gérer ou non la validation des paramètres non-typés, ... c'est pas la joie.
Oh et il ne faut pas oublier de mentionner les variables déclarées sans type, avec un traitement 3 pages plus loin qui se base sur leur valeur par défaut. Quelle valeur par défaut ? Ben ça dépend de l'instruction dans laquelle la variable est utilisée en premier. Et c'est pas forcément la même selon l'endroit dans le traitement.
Bien sûr, les conversions automatiques sont censées masquer tout ça et empêcher qu'il y ait le moindre problème. Sauf que non.
Moralité : Option Strict On -> à rendre obligatoire. C'est un peu plus fatiguant pour le dév initial (qui doit faire attention à ce qu'il fait et passer des paramètres valides, mince alors), mais ça évite de gêner le reste du monde ensuite et ça évite aussi pas mal de bugs bien vicieux.
Je trouve très con que VS.NET n'active pas cette option par défaut quand on crée un nouveau projet. Au moins ça active Option Explicit, c'est déjà ça. Mais les deux ont besoin d'être activées pour faire disparaitre les principaux arguments contre VB. Ensuite on peut le comparer aux autres langages "à armes égales".
bon bon, j'ai mal aux yeux en lisant ce débat... 18 pages que je viens de bouffer, c'est pas rien :)
Quand j'étais encore aux études supérieures, on nous a appris le C, pascal, C++ et Java et VB6
durant mon stage, la cellule informatique ou je travaillais, programmais encore en VB6 et je vous assure que ce sont des pros VB6 et ce qu'ils ont fait étaient magnifiques!!! jamais je n'aurai imaginé qu'avec ce "vieux" langage, on pouvait faire de telles choses.
pour vous situer, il s'agit d'applications pour l'informatique de diffusion, donc qui font du monitoring pour la diffusion d'un journal télévisé, application de recherches d'archives sur 21 années, application de numérisation, etc... j'en passe et des meilleurs.
alors quand je suis arrivé, ils m'ont proposé de faire du .NET
bon... .NET... C# ou VB.NET (sachant les langages appris à l'école, je m'étais plus penché vers le C#) mais finalement vu que mes maîtres de stages étaient des pros en VB6, je me suis dit qu'ils pourraient m'aider en VB.NET vu que c'est très proche.
c'est alors que pendant 4 mois je n'ai fais que du VB.NET et j'adore ce langage! très facile à apprendre, à manier, lisible, etc...
depuis la fin du stage, j'ai été engagé dans leur cellule et j'ai du me refamiliariser avec le VB6 et je vous assure que quand on repasse du VB.NET au VB.6... C'est pas amusant... c'est comme ci on passait d'une BMW à une renault 5...
bref aujourd'hui je me pose encore la question!
C# ou VB.NET car après les 18 pages du débat, je ne me suis toujours pas décidé!
le C# pour se familiariser, c'est pas dur, vu que j'ai déjà appris le Java, C/C++
mais pour l'instant j'ai envie de migrer vers le C#, pourquoi?
- tout simplement comme l'a mentionné un membre, pour des raisons commerciales. ca fait un "chouïa" plus sérieux dans un CV. MEME si je suis d'accord, cela ne change absolument rien, pour les performances, je m'en fou pas mal, vu que les 2 langages présentent des avantages/inconvénients.
- Beaucoup plus de sources et d'aides dans ce langage C#
- Sécurité pour l'avenir, je m'explique :
mon point de vue est de dire, pour me mettre à l'abri d'un C4 (très optimiste hein!), je préfère migrer vers le C# car tout simplement il est la quasi-copie du JAVA et ressemble très fort au C++
ce qui me permettra de trouver du boulot plus vite en JAVA/C++/C# tandis que le VB.NET... Quel langage mettre dans le CV a part VB6?
et j'ai entendu dire que l'avenir du VB.NET n'est pas très riche car microsoft aurait des tendances à faire du C# LE langage du .NET???
voila j'aimerais connaitre vos avis sur manière de penser.
Salut,Citation:
Envoyé par Dnx
D'un point de vue professionnel à mon avis vaut mieux connaitre les 2 (VB.NET et C#). Tu peux te spécialiser dans celui que tu préfère mais ca fait pas de mal de faire de temps en temps un petit projet dans l'autre.
De toute façon, pour un boulot, au bout d'1 ou 2 semaine de dev, si tu connais bien le FrameWork, les petites différences du nouveau langage seront vite acquise.
Ben en regardant les votes, il ne faudrait pas trop oublier le troisième larron Delphi.Net :) , je m'y suis mis depuis quelques temps et j'y prends goût
- propreté absolu
- simple de manipulation une fois pigé l'architecture
- l'encapsulement d'une grande partie de la framework par la VCL, augmentant pas mal les possibilités
- pas autant de soucis de migrations que le vb6
j'avoue que pour l'instant je n'ai pas prêté attention à des désavantages
Je pense qu'on recommencera le sondage avec l'arrivée de .NET 2.0 car certains argumentaires deviendront obsolètes ;)
Concernant delphi .NET ce qui me chagrinne le plus c'est que delphi .NET aura toujours semble t'il une guerre de retard sur la dernière version du framework. Et quand on voit les énormes nouveautées de la V 2.0 : http://lgmorand.developpez.com/dotnet/framework2/ on peut pas conseiller à quelqu'un qui veut se mettre au developpement dotnet d'utiliser un langage qui utilise un framework "obsolète".
L'interet de delphi vient à mon avis de la compatibilitée avec les versions antérieures de delphi car borland à trés bien réussit la migration en douceur contrairement à microsoft...
8O Là je te trouves durdur Neo, j'espère que la framework 1.1 n'a pas été totalement réécrite dans la 2.0 :lol: elle a plutôt été complété non :?:Citation:
Envoyé par neo.51
C'est pour ça que j'ai mis entre guillemets :lol:
Mais une fois que .NET 2.0 sera vraiment sortit, tous les frameworks qui gravitent autour de .NET vont passer en 2.0 et vont évoluer en .NET 2.0, pareil pour tous les composants (ne serais ce que parce que la version 2.0 introduit les générics).
Résultat en delphi .NET qui utilise .NET 1.1 tu vas être obligé d'utiliser des versions plus anciennes des frameworks et des composants "Tiers".
Bon en même temps delphi 2006 devrait sortir en 2006 donc il faut s'attendre à 6 mois 1 an de retard...
Ben moi j'appelle çà de la sagesse :wink: autant attendre 6 mois que le produit ne soit plus du bêta et a eu le temps d'être stabilisé :)Citation:
Envoyé par neo.51
J'arrive un peu après la bataille, mais...
J'ai aussi vu l'inverse. Un client qui préféreait un produit en VB.Net plutôt qu'en C#, parce que VB c'est plus simple (c'était juste un développement, la maintenance restant à la charge du client). Alors qu'effectivement, la différence est quasi-nulle...Citation:
Pour des raisons un peu historique et même si aujourd'hui cela ne correspond plus rien techniquement parlant, : C (fut-il Shap), c'est plus vendeur que Basic (fut-il .Net)
Combien de fois ai-je vu la mine déçu de mes clients quand ils apprennent que leur produit, dont ils sont pourtant content est écrit, en BASIC.
Par contre quand on leur parle de C ou Pascal, cela fait tout de suite plus sérieux.
Donc C ça fait pro, mais ça fait aussi peur (inacceessible) pour les non-initiés. Du coup, c'est un argument à double tranchant.
Certainement, mais connaissant les gens de ressources humaines, je suppute qu'ils raisonnent aux nombre de langages énumérés (sachant qu'il faut qu'ils en aient déjà entendu parler). Je pense qu'un développeur VB.Net peut sans trop mentir mettre C#sur son CV (quitte à lire la doc un soir), vu la proximité des 2 langages. Et ce sear certainement ça le plus vendeur.Citation:
Idem dans CV. Pour un certain nombre de décideurs (certain n'ont jamais vu un clavier) BASIC reste synonyme d'amateur alors que C a une conotation pus sérieuse. A moyen terme, je pense qu'un programmeur C# se vendra mieux qu'un programmeur VB.
--
ROm_1
Loin de moi l'idée de vouloir 'troller' mais sérieusement on a pas du voir le même produit. Autant les précédentes versions de Delphi avaient bonne réputation (à juste titre d'ailleur) autant la version 2005 m'a paru instable au plus haut point. Je suis désolé mais sur un portable 1,4Ghz 384 Mo ca met 6 minutes montre en main à ce lancer (pratique pour aller chercher un café à la machine :lol: ). Par rapport aux articles dithyrambiques que j'ai pu lire ici et là, mon expérience est plutot inverse et j'ai eu l'impression d'un produit non fini (peut-être il y a t il eu des patch depuis).Citation:
Envoyé par neguib
Mais, si on laisse de coté l'IDE, le problème principal à mon sens, est lié au Pascal lui même : Le fait de ne pas pouvoir déclarer de variables ou d'instancier un objet localement ( contrairement au VBNET/C#/C++/JAVA ).
Exemple ( corrigez moi si je me trompe) :
Ou quand on veut faire du GDI+ par exemple :Code:
2
3
Avec Delphi, sauf erreur, il faut absolument déclarer en haut de prog un objet SolidBrush et un objet Rectangle alors qu'on va l'utiliser qu'une fois localement. Sur routine complexe ca deviens vite le bordel, entre les boucles et le reste on se retrouve avec une tonne de déclarations au départ qui se mélange aux variables privées utiles.Code:G.FillRectangle(new SolidBrush(Color.BackColor),new Rectangle(0, 0,20,20));
Maintenant je ne suis pas spécialiste peut être quelqu'un de plus expérimenté en Delphi pourra me détromper sur ce point.
En conclusion je pense, et ca n'engage que moi, que Delphi (6) est une trés bonne plateforme de développement en WIN32 mais je ne suis pas convaincu par la version 2005 et le mélange Pascal / .NET.
Ben sur mon vieux AMD qui connait pas le Ghz çà met moins de 15 secondes :lol:Citation:
Envoyé par Kikos31
Ben oui tu te trompes :roll:Citation:
Envoyé par Kikos31
Code:
2
3
4
5
6
7
8
La faq delphi.Net te demontrera totalement le contraire :)Citation:
Envoyé par Kikos31
Je crois que tu n'as pas bien saisie le problème :D , ton exemple illustre justement ce que je dis. Pour ta boucle tu es obligé de déclarer la variable i en début de prog :Citation:
Envoyé par neguib
alors qu'on en a rien a faire hors de la boucle il est déclaré en début de procedure et reste accessible jusqu'a qu'on la quitte.Code:
2procedure machin; var i:integer;
Ce qui est encore plus embêtant c'est de ne pas pouvoir faire de new dans un constructeur sans passer par des variables à chaque fois (cf mon exemple GDI+). J'espère être + clair.
Je te renvoi également à la FAQ :wink: .
A mon avis c'est toi qui ne comprends pas grand chose :lol: une procedure est un membre donc j'ai bien déclaré une variable locale, j'aurai très bien pu mettre dans un constructor ou une FunctionCitation:
Envoyé par Kikos31
C'est de l'Objet strict l'ami, en dehors de ces membres il y aussi des declarations au niveau de la classe, en fait rien de surprenant. Montre moi ce que tu ne sais pas faire je te montrerai comment le faire :lol:
Mon cher Neguib reste calme, tu t'enfonce :roll: . Comme tu le remarque si bien ta variable est de portée locale. Mais, en pascal, au minimum sa portée est sur toute une procedure/fonction. Dans les autres langages que j'ai cité tu peux déclarer des variables uniquement là ou tu en a besoin au sein de ta procedure/fonction, sa portée peut être juste une boucle (VB/C#).Citation:
Envoyé par neguib
Quand tu aura compris, relis ce que j'ai marqué précedement tu verra en quoi ca peut être génant à mon gout. Si tu comprends toujours pas je te cite un cours de C++ :
Citation:
Exemple 1-8. Définition de variables
int i=0, j=0; /* Définit et initialise deux entiers à 0 */
double somme; /* Déclare une variable réelle */
Les variables peuvent être définies quasiment n'importe où dans le programme. Cela permet de ne définir une variable temporaire que là où l'on en a besoin.
Merci l'objet je connais un peu :lol: y parait que c'est mon metier. D'ailleurs le problème n'a absolument aucun rapport avec la POO :roll: .Citation:
Envoyé par neguib
C++ POWER !!!!!!!!!!!!!!!!!!!!!!!!!!!
et oui il en reste... je dis ca parce que j'en est marre des languages trop évolué qui te permette de desiner a la souris des IHM et autres solutions de noobie. Y a plus aucun merite a etre developpeur/ingénieur informatique si ton seul boulot c'est t'amuser avec la souris, cliquer sur des bouton et boucher les quelques trou de codes... En plus c'est des langages super lents (oui je sais avec un P4 3Giga ca va pas trop mal, mais j ai pas les sous pour m offrir ca) vu qu'il sont interprétés. En plus on donnant plus de facilité on perd des possibilités, on est prisonnier de beaucoup plus de contraintes
Voila c'etait mon avis tres intrressant :fou:
Ah tiens, j'aurai appris un truc :)Citation:
Envoyé par Kikos31
(je vais peut-être avoir à en faire prochainement, va falloir que je me documente dessus :)
Et donc oui, si on ne peut pas déclarer de variables limitées à une portée (boucle/test), c'est pas glop quand on y est habitué dans les autres langages :)
Bon par contre, au niveau des méthodes c'est déjà suffisant. Si tu te retrouves avec un pavé de 50 variables, c'est que ta méthode est bien trop grosse. Ça encourage à décomposer davantage, et ça c'est plutôt un bon point.
Pas d'accord, en informatique, comme dans n'importe quel métier, l'objectif n'est pas de faire les choses de la façon la plus puriste possible, c'est surtout de gagner de l'argent, or le temps c'est de l'argent ! Sérieux, qui voudrait passer des heures à développer des IHM alors que des IDE te permettent de le faire aussi bien et bien plus rapidement, afin de ne concentrer ton temps qu'aux développements les plus spécifiques et\ou plus complexes où tu peux apporter une réelle plus value.Citation:
Envoyé par BainE
Ca sert à rien de réinventer la roue à chaque fois que tu veux construire une voiture !
Si tu en fait n'hésite pas donner ton avis sur ce produit, il n'y a pas eu beaucoup de retour dessus. D'ailleurs si il y a des dev professionnels qui utilisent Delphi2005 dans le boulot, exprimez vous...Citation:
Envoyé par Maniak
Tu as raison dans le principe mais dans les faits même sur proc/méthode de taille moyenne ça fait vite fouilli. J'en veux pour exemple le dernier source publié qui est en C# et en Delphi.net :Citation:
Envoyé par Maniak
http://zewaren.developpez.com/dotnet/textmosaic/
Si on regarde la procedure principale dans les 2 versions, ca donne une idée du problème.
Encore une fois ce n'est que mon avis, il y a peut être d'autres qualités qui viennent compenser.
J'essayerai :)Citation:
Envoyé par Kikos31
Je suis notamment curieux de savoir comment ça se passe pour les projets en Delphi pré-.NET. Est-ce qu'il y a moyen de les porter facilement (dans le sens vrai portage, pas dans le style du portage commercial VB6->VB.NET ou ASP->ASP.NET qui sont complètement pipeaux), est-ce que l'IDE supporte à la fois Delphi et Delphi.NET ou est-ce qu'il faut garder l'éditeur Delphi tout court.Citation:
Envoyé par Kikos31
Button2_Click ?Citation:
Envoyé par Kikos31
C'est vrai que ça fait fouillis, mais ça rentre aussi dans la catégorie des méthodes longues qu'il faudrait raccourcir. Là ça irait très certainement beaucoup mieux :)
En sortant le premier test, la boucle et le test dans la boucle, ça ferait déjà beaucoup plus court.
Voire en sortant tout le traitement dans une nouvelle classe, auquel cas l'essentiel des variables deviendraient des champs. Encore plus court et très certainement plus clair :)
Pour les autres méthodes, y a pas de problème particulier. Mais c'est clair que ça chatouille de ne pas pouvoir déclarer les variables uniquement quand on en a besoin, là où on en a besoin :)
Ici, je travaille avec Visual Basic.NET, sans honte :yaisse2:
Pour des raisons personnelles (allergie aux pointeurs...). Farce à part, c'est un langage qui me plaît particulièrement, et qui m'a réconciliée avec le développement (pour l'avoir laissé plusieurs années...).
Alergie aux pointeurs: en object tout est pointeur...
Et en .NET, ils sont tous gérés via des références + GC peu importe le langage. C'est un argument pour .NET (ou Java d'ailleurs :), mais pas pour VB.NET spécifiquement :)Citation:
Envoyé par lololefada