Discussion :

[DonQuiche]

@Richard Trigaux
La plupart des langages utilisent ce que nous appelons la syntaxe C et se ressemblent beaucoup à cet égard. Il y a donc bel et bien un effort d'homogénéisation.

Mais il n'est pas possible d'aller beaucoup plus loin sans sacrifier les spécificités de chaque langage : tu as besoin d'un côté de langages souples mais lents comme le PHP et de l'autre de langages rigides mais rapides comme le C/C++. Quelques efforts partiels de fusion existent : le D mélange monde managé et monde non-managé. Le C# à base de typage fort permet aussi le support du typage faible et quelques éléments de programmation fonctionnelle. Mais tout ça se fait au détriment de la simplicité : ces langages deviennent de plus en plus compliqués à apprendre. Ce ne sont pas des rêves de débutant. Et puis figer les langages, ça voudrait dire figer l'évolution : tu imagines si toute l'industrie avait décidé de s'en tenir au C++ il y a vingt ans ?

Quant au PHP, beaucoup d'entre nous le trouvent indigeste avec ses "$" avant chaque variable et ses underscores à tour de bras. Je devine que tu as commencé par lui en revanche, d'où ta vision des choses. Quant au "===", lui, il a toute raison d'être, tu récidives. :-(

Enfin, j'aimerais insister sur un point : le but des langages n'est pas d'être simples et faciles à apprendre. Leur but est d'offrir de la puissance à ceux qui les maîtrisent. Qu'on nous laisse nos opérateurs ternaires, de coalescence, nos tail calls, nos closures, nos... Le développement est avant tout une industrie avec des besoins, pour des pros. Autant je peux applaudir toute initiative visant à susciter davantage de vocations ou à permettre de la petite programmation (ah ! si les vendeurs de mobiles pouvaient en standard intégrer de quoi bidouiller comme d'autres ont pu le faire sur leurs calculatrics il y a quinze ans), autant ça ne sera jamais le coeur des besoins.

[Bluedeep]

Tu te rends compte de ce que ça veut dire ?

Pour avoir lu ses derniers posts, je réponds sans hésitation : NON.

J'ai peut-être pris un exemple trop simpliste en fait. La gestion du typage et même les différents types sont des caractéristiques propres à chaque langage et il y a une raison. Pas pour em**rder le néophyte et faire briller le crâne de ceux qui maîtrisent mais pour permettre une optimisation de chaque langage pour chaque usage spécifique.

Te fatigue pas trop .

Passer du temps à expliquer à des débutants, je veux bien, en perdre avec quelqu'un qui ne connait rien mais qui pense avoir la science infuse,pour ma part, je m'y refuse.

[gwinyam]

Pour avoir lu ses derniers posts, je réponds sans hésitation : NON.

Te fatigue pas trop .

Passer du temps à expliquer à des débutants, je veux bien, en perdre avec quelqu'un qui ne connait rien mais qui pense avoir la science infuse,pour ma part, je m'y refuse.

La nature m'a fait tête de mule

Quant au "===", lui, il a toute raison d'être.

C'est très vrai en PHP et c'est encore plus vrai en Javascript. Essaie donc de faire un code très complexe avec == et refais le avec ===. Puis déclenche une batterie de tests digne de ce nom. Je te parie sans aucun souci que la première version va lâcher bien plus vite que la seconde.

[Niark13]

Code :

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

Quelques efforts partiels de fusion existent : le D mélange monde managé et monde non-managé.

Non. Le D possède un garbage-collector, mais n'utilise pas de machine virtuelle. C'est un langage natif pur.

[dewind]

Excusez moi, mais c'est un peu comme si on demandait au médecin de ramener la médecine au niveau de M. Toutlemonde qui n'a jamais fait un semestre de médecine.

Je dirais en plus que la maîtrise d'un langage et de ses subtilités ça met du temps, du travaille, de l'application. Ceci, pour les novices, comme pour les développeurs confirmés (lorsqu'il s'agit de changer de langages).

Si je puis me permettre, en ce qui me concerne, je touche à plusieurs langages, juste assez pour dire que je peux "me défendre" sur un certain nombre de plate-forme. Toutefois, si je veux maîtriser un langage de font en comble pour faire des applications les plus performantes je dois bosser afin de maîtriser les langages.

De plus s'il se donnait la peine de travailler sur certains langages "obscurs" (ne suivez pas mon regard) il connaitrait sa chance.

Enfin, moi ce que j'en dit.

[zeyr2mejetrem]

De plus s'il se donnait la peine de travailler sur certains langages "obscurs" (ne suivez pas mon regard) il connaitrait sa chance.

On veut des noms !

[Hrungnir]

Bonjour,

Je crois que ce journaliste a raison sur le fond.
Certes, il s'exprime de manière imprécise, certes il fait un procès d'intention aux créateurs de langage, mais son analyse n'est pas sans fondement.

Il y a quelque dizaines d'années en informatique, je crois qu'il existait parmi les "simples utilisateurs" une proportion non négligeable de bidouilleurs et de curieux, qui sans avoir de formation particulière (formation qui n'existait pratiquement pas du reste), trouvait un certain plaisir à comprendre comment tout ça marche, et à faire des petits programmes soi-même.
Je crois que le journaliste se trompe en définissant deux "camps" : les utilisateurs et les développeurs. Il y a, à mon avis, parmi les utilisateurs, une grande majorité de personnes qui ne veut surtout pas toucher à du code, qui à trop peur de tout casser, etc. Mais il y a aussi des gens curieux qui aiment bien expérimenter et essayer par eux-mêmes. Ils n'ont pas tous l'âge/le temps/les capacités de devenir de vrais programmeurs professionnels, ça n'est pas un mal en soi. On pourrait très bien imaginer que parmi les centaines de langages existants, certains soit dédiés à des débutants ou des enfants.

Pour reprendre un contre-exemple qui a été cité, il existe des logiciels de simulation de pilotage. Pour permettre à des gens dont ce n'est pas le métier de faire "comme si" et de s'amuser à apprendre à piloter sans la contrainte et l'exigence d'un vrai pilotage.
Pourquoi n'existerait-t-il pas des logiciels ou même des langages de simulation de programmation ?
C'est un "besoin" qui existe, évidemment c'est complexe à mettre en place mais peut-être y-a-t-il un "public" non négligeable pour ce type de produit (enfants, journalistes désoeuvrés, etc).

Donc, non il ne faut pas revoir les fondements de la programmation, ni toucher au C, etc
Mais c'est vrai que des efforts pour rendre la programmation plus accessible sont envisageables.

[zeyr2mejetrem]

Donc, non il ne faut pas revoir les fondements de la programmation, ni toucher au C, etc
Mais c'est vrai que des efforts pour rendre la programmation plus accessible sont envisageables.

Les langages (très) haut-niveau pour bidouilleurs existent.
Seulement ce journaliste part dans le mauvais sens. Il a voulu cibler la plateforme Iphone, or Apple n'est pas très "ouvert" aux développeurs non professionnels (c'est juste mon opinion) ou venant d'autres technos.

[dewind]

Les langages (très) haut-niveau pour bidouilleurs existent.
Seulement ce journaliste part dans le mauvais sens. Il a voulu cibler la plateforme Iphone, or Apple n'est pas très "ouvert" aux développeurs non professionnels (c'est juste mon opinion) ou venant d'autres technos.

Je serai même tenté d'ajouter que, je ne peux pas "débarquer" sur un langage et chercher l'ultime maîtrise, non ? (Soit dit en passant parce qu'il arrive que je patine dans la choucroute même quand je suis censé connaitre assez bien un langage).

Au final moi ce que je dis (n'engageant que moi) quand on fait quelque chose comme ça il va de la persévérance et non briser tout parce qu'on arrive à rien .

[zeyr2mejetrem]

Au final moi ce que je dis (n'engageant que moi) quand on fait quelque chose comme ça il va de la persévérance et non briser tout parce qu'on arrive à rien .

+1

[vpntool]

Je pense qu'il existe deux types de développeurs : bidouilleur ou pro pour deux types d'application : petite application et gros logiciel.
C'est la différence entre un codeur et un ingénieur logiciel.
De prendre un framework MVC et développer en objet dans un language évolué est indispensable pour réduire les coûts de maintenance qui exploseront lorsque l'applicatiobn deviendra trop importante. Mais si l'application n'est pas faite pour devenir trop importante alors sa maintenance n'explosera pas ... On ne développe pas un intranet collaboratif comme on développe un convertisseur Euro.

Si vous voulez construire un immeuble prennez un architecte si vous voulez faire une cabane à jardin faites en l'économie !
Laissons donc chacun à sa place , tout est histoire de bon sens.

Un petit article évoquant la complexité de la POO notament pour les débutants :

http://vincentpoiron.over-blog.com/a...-86018894.html

[Yo Eight]

Ce sujet se rapproche assez d'un autre parlant de l'apprentissage de la programmation en quelques heures avec l'aide d'un bouquin.

Le problème c'est que ce genre de personnes veulent contraindre un langage de programmation à leur perception de celui-ci. Que se passerait-il si j'appliquais ce genre de raisonnement dans des domaines que je ne maîtrise pas comme la physique quantique => une catastrophe !

On peut cependant reconnaître des complexités accidentelles dans certains langages comme:

- le concept NULL ou la fameuse erreur à 2 milliards de dollars.

- l'implémentation de (==) dans des langages managés comme Java où dans 99% du temps on s'en fout de comparer en terme de référence. D'ailleurs Scala a fusionné le (==) avec equals. C'est le compilateur qui détermine quelle stratégie utilisée.

Utiliser un langage particulier c'est accepter une certaine façon de pensée.

Que signifie revoir les fondements de la programmation ?

Vous prenez 2 Gourous dont un en C et l'autre en Haskell, ils vous donnerons des fondements totalement différents !

[BenoitM]

Beuh on pourrait quand même imaginer une plus grande uniformisation

Pourquoi avoir appeller "Null" "Nothing" en VB
Pourquoi avoir des bigint, tinyint en sqlserveur des double, short en c like...
Pourquoi ne pas utiliser maintenant Int16,Int32,Int64 partout
Pourquoi ne pas avoir de notion de boolean en sqlserveur

Ca rendrait la vie plus facile aux développeurs mais il faudra quand meme être developpeur

[dewind]

Beuh on pourrait quand même imaginer une plus grande uniformisation

Pourquoi avoir appeller "Null" "Nothing" en VB
Pourquoi avoir des bigint, tinyint en sqlserveur des double, short en c like...
Pourquoi ne pas utiliser maintenant Int16,Int32,Int64 partout
Pourquoi ne pas avoir de notion de boolean en sqlserveur

Ca rendrait la vie plus facile aux développeurs mais il faudra quand meme être developpeur

Là c'est sûr qu'un petit coup de pouce comme ça ce serait pas mauvais. Mais toujours est il qu'il faille un minimum d'effort pour en bénéficier.

[Bluedeep]

Beuh on pourrait quand même imaginer une plus grande uniformisation

Pourquoi avoir appeller "Null" "Nothing" en VB

"null" a été popularisé par des langages de la "C-Family" (et par le SQL).

VB a pour antécesseur les "basic", et jusqu'à .Net, aucune convergence entre ces familles n'étaient vraiment prévu.

Pourquoi avoir des bigint, tinyint en sqlserveur des double, short en c like...

Déjà, la considération 'C like' est ici hors de propos, car le C diffère largement de la C Family de ce coté, en ce sens qu'il dispose de typage "naturels" (platform dependent) at d'autres qui ne le sont pas; un certain nombre de langages de la 'C Family' n'a aucun typage 'platform dependent' (un int ou un short en C# a la même signification sur un x86 ou sur un processeur 64 bits).

Ensuite le SQL standard est antérieur à la popularisation des langages 'C Family' et par ailleurs on ne voit pas très bien pourquoi il devrait adopter un des typages des langages d'exploitation des couches supérieures plutot qu'un autre.

Pourquoi ne pas utiliser maintenant Int16,Int32,Int64 partout

Pour des raisons évidentes que j'ai exposées très partiellement supra.

Pourquoi ne pas avoir de notion de boolean en sqlserveur

Il existe en T/SQL le BIT, qui ne peut prendre que deux valeurs,mais qui ne permet pas il est vrai d'opérations booléennes directes.
En revanche le Boolean existe en PL/SQL (mais pas comme type de stockage, sous réserve de vérification, car je ne connais pas aussi bien Oracle que Sql Server).

[DonQuiche]

@Bluedeep
Autant pour le SQL, de par son ancienneté, on peut comprendre : il est hors de question pour les anciens langages de s'uniformiser au risque de rompre la compatibilité. Mais VB en revanche... Oui, MS a cherché à imiter le basic mais pourquoi ? Ça n'avait aucun intérêt. Parce que c'est supposé être plus simple ? C'est du vent selon moi : apprendre les mots clés "null", "short", et autres n'a jamais été le problème d'un développeur débutant. Autant mettre un sparadrap sur un jambe gangrenée ! En faisant ainsi on ne simplifie pas la tâche pour le nouveau développeur mais on la rend plus complexe pour le chevronné. Qu'on appelle le langage "basic" par souci marketing, soit, mais pousser le vice jusqu'à réellement imiter le basic, c'est de la perversité pure et simple.

Et puis, il y a d'autres exemples... Pourquoi "nil" dans certains langages ? Pour économiser un caractère ? Certes, fondamentalement ça a un intérêt pour le parsing mais, en pratique, l'économie sera t-elle significative pour justifier ce choix ? Non. Ou encore les commentaires débutant par "--" en LUA ?

Bref, oui, certaines différences sont justifiées. Mais reconnaissons que d'autres ne sont là que pour se singulariser.

[Bluedeep]

Pour le VB, ton argumentation se tient relativement, mais il faut comparer aux autre langages de l'époque (VB 1.0 : 1991 ); au moment où VB est sorti le concept même de null n'existait (de fait, dans les langages réellement utilisés) qu'en C ("null"), Pascal ('NIL') et SQL (encore que je ne sois pas certain qu'à cette date NULL faisait partie de la norme) - peut être aussi ADA, je ne sais pas. Il était ignoré par COBOL qui représentait "une bonne partie" du code écrit, et par FORTRAN, ainsi que par pas mal de L4G en vogue à ce moment.

Et puis, il y a d'autres exemples... Pourquoi "nil" dans certains langages ?
Pour économiser un caractère ?

J'aurais plutôt dit par homophonie avec le latin nihil, qui était parfois orthographié en nil
De plus, NIL est en LISP la liste vide (je crois).

[BenoitM]

Je n'ai pas du qu'il n'y avait pas de justification

Juste que des efforts de convergences seraient les bienvenues.

Il me semble par exemple que la norme SQL n'avancait pas assez vite donc Oracle et SQL-Serveur ont implémenté leurs propre fonctions (manipulation de chaine, de date,...) hors ensuite la norme SQL les a définies.
On pourrait imaginer que Oracle,SQL Server,MySQL ajoutent ces nouvelles fonctions tout en gardants les leurs pour des raisons de compatibilité.

C'est un peu lourd parfois de devoir chercher le nom d'une fonction parce que tu changes de base de données

[Bluedeep]

Je n'ai pas du qu'il n'y avait pas de justification

Juste que des efforts de convergences seraient les bienvenues.

SAuf que dans les exemples que tu fournis, tu voudrais voir une convergence dans le mauvais sens (les "anciens" qui devrait d'adapter aux "nouveaux").

Il me semble par exemple que la norme SQL n'avancait pas assez vite donc Oracle et SQL-Serveur ont implémenté leurs propre fonctions (manipulation de chaine, de date,...) hors ensuite la norme SQL les a définies.

Si on prend l'exemple de T/SQL et PL/SQL, certaines notions dans ses deux langages sont totalement antinomiques et ne supportent pas la convergence. Un exemple : le concept d'espace de données retournée par une PS est un concept du T/SQL totalement ignoré par PL/SQL; PL/SQL lui est de plus clairement basé sur une syntaxe de type Pascal, alors que T/SQL est une extension à SQL (d'ailleurs SQL SERVER ne distingue pas un bloc T/SQL d'un bloc SQL standard, alors que Oracle distingue les deux langages).

On pourrait imaginer que Oracle,SQL Server,MySQL ajoutent ces nouvelles fonctions tout en gardants les leurs pour des raisons de compatibilité.

C'est avec ce genre d'idée qu'on fabrique un truc comme VB.Net qui n'en finit pas de se débarasser de ses verrues de VB6 pour des raisons de compatibilité.
T/SQL et PL/SQL (je ne connais pas le dialecte SQL de MySQL et ne sais même si il a des spécifités) sont des langages d'une extrème puissance pour ce qu'ils sont censé faire et on ne voit pas bien le bénéfice qu'il y aurait à leur faire des ajouts syntaxiques "de confort" qui ne ferait que les compliquer et de surcroit créer des problème de compatibilité (tout ajout d'un mot clef dans un langage créant a priori des problèmes avec le code existant - de plus avec le SQL, tu ne peux pas dire "je laisse tel proc stoc dans le version n - 1" comme tu peux le faire avec des langages compilés).

C'est un peu lourd parfois de devoir chercher le nom d'une fonction parce que tu changes de base de données

Moins que d'avoir trois fois la même fonction pour faire la même chose avec l'inconsistance de relecture et de maintenance que cela entraine.

Je trouve que ton analyse manque un peu de recul : tu proposes des solutions à des problèmes qui n'existent pas vraiment mais qui sont susceptibles d'en créer des vrais (de problème).

de plus, dans le cas de Sql Server, si le T/SQL t'emmerde, tu peux (presque ?)tout coder en C# si tu veux (avec le SQLCLR/C# pour remplacer le DDL et les C# + SMO pour remplacer le DML).

[BenoitM]

Beuh en java et en .net on mais bien certains fonction du framework en obsolete et ca pose pas de problème

Je vois pas en quoi ajouter la fonction CONCAT a SQL Serveur serait un drame
Est-ce que les utilisateurs d'Oracle sont si perturbé parce qu'il peuvent utiliser CONCAT et || ?

Je vois pas en quoi ajouter TO_DATE(date,format) à Sql Serveur serait parce que je trouve qu'il est plus facile de retenir dd/mm/yyyy que CAST(date,datetime,103)

De plus en mySQL tu ucase upper et c pas moi qui l'ai demandé