Discussion :

[gangsoleil]

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

Ah bah si, ca en pose regulierement lorsqu'il faut reprendre du vieux code (genre une bonne grosse application en prod depuis plusieurs annees) et que la moitie des fonctions ne sont plus utilisables. Et non, on n'a que tres rarement les budgets necessaires pour re-ecrire l'application.

[Bluedeep]

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

Va expliquer cela aux DBA qui ont par exemple un schema/table/vue/champs ou variable dans une PS qui s'apelle CONCAT par exemple.

Est-ce que les utilisateurs d'Oracle sont si perturbé parce qu'il peuvent utiliser CONCAT et || ?

Tu poses une fois de plus la problème à l'envers mais comme je te l'ai déjà dit ..

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)

idem. cf. supra.

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

Je ne connais pas MySql.

[dewind]

Hum voilà qui donne une certaine tournure à la question.
Il est clair que lorsque l'on utilise plusieurs langages, on est obligé de savoir jongler entre plusieurs structures, formulations et autres...

Toutefois je pense que c'est ce qui fait le charme et la difficulté. (Ce qui fait que souvent on peut se tromper, lorsqu'on utilise l'une ou l'autre.

Maintenant cela m'emmène à poser une question. Doit on se sédentarisé dans un seul langage (ou style de langage), ou plutôt avoir des connaissances diverses dans plusieurs langages ?

[BenoitM]

Doit on se sédentarisé dans un seul langage (ou style de langage), ou plutôt avoir des connaissances diverses dans plusieurs langages ?

Je pense qu'en général on se sédentarise souvent à un "langage de programmation de base (c#, vb.net,java,...)

1) Le temps de connaitre un framework est assez long
2) Il est plus facile de valoriser les comptétences déjà aquises
3) L'entreprise à souvent choisi une voie et donc tu n'auras plus de contact avec d'autres langages
4) Il est déjà difficile de rester à jours dans son domaine

Maintenant pour programmer tu es souvent confronter à d'autres langages.
Il faut un minimum de SQL, si tu travaille en web d'html ,...
Il y a aussi les projets de migrations qui te confronte à d'autres langages, mais je ne pense pas que savoir lire un code, le modifier soit suffisant pour considérer qu'on maitrise un langage

[dewind]

Ce qui m'oblige à poser une question :

- Ne faudrait-il pas "maîtriser" au moins un langage de Programmation Orienté Objet. Et aussi un langage procédural.

- Un ou deux gestionnaire de BD quelque peu différents.

Parce que je me dis qu'à force de travailler sur différents systèmes, on aura moins de difficultés lorsqu'on est confronté aux migrations.

[cap_gregg]

Bonjour,

à mon avis les langages 'physiques' ne sont pas l'avenir, nous devrions progressivement voir apparaître des langages 'logiques' graphiques beaucoup plus simples.

Un exemple est le requêtage : avant l'apparition du langage SQL, les développeurs devaient coder leurs requêtes 'physiquement'. Il fallait lire une première table enregistrement par enregistrement, puis faire les jointures pas à pas en lisant d'autres tables, etc.

Cela demandait une quantité de code énorme.

Avec l'apparition du SQL, les requêtes ont pu être exprimées de manière entièrement 'logique'. C'est le langage qui détermine un plan d'actions physiques (en fonction des données et de l'environnement disponible), et qui exécute ensuite ce plan.

Avec le SQL, on s'est aperçu que "exprimer une logique" était infiniment plus simple que de la coder physiquement.

Malgré ces progrès, programmer reste à ce jour encore très lié au physique : je mets mes résultats dans un table temporaire, table que je reprends ensuite, etc. Quand on prend un code donné, et qu'on s'amuse à regarder ce qu'il fait "réellement sur un plan logique", on s'aperçoit qu'il y a 'énormément' d'énergie dépensée pour des résultats maigres.

Comme le SQL l'a montré, passer à un niveau logique n'est pas seulement plus simple : c'est aussi plus court, plus sûr, et surtout plus productif. Pour ces raisons, il est donc incontournable que nous allions vers des langages logiques.

Mais on peut prédire que l'avenir sera 'plus simple encore'.

Pour rester sur l'exemple du requêtage, nous connaissons tous les outils de requêtage graphique comme Business Objects (BO), qui sont une ultime simplification (par ex. BO retient les liens entre tables, il n'y a même plus à les coder).

BO simplifie le SQL, alors que le SQL est lui même une simplification du codage.

De manière générale, les logiques de traitements se prêtent parfaitement à une représentation graphique. Certains langages, comme les ETL, commencent à proposer cette programmation logique graphique. Les macro opérations (lectures/écritures, jointure, tri, filtre, ...) sont représentées par des symboles, qu'on enchaîne en les reliant par des traits (un peu comme du shell graphique, les traits étant les 'pipes').

Avec ces langages logiques et graphiques à base de symboles, la logique des traitements (opérations, enchaînements) n'est plus stockée dans des 'programmes' : elle est stockée logiquement dans des bases de données référentielles. Ce stockage logique apporte de nombreux avantages : par exemple il devient simple de faire de l'analyse d'impact (si je change ceci, quels impacts ? quelles sont toutes les manières d'alimenter cette donnée ?).

Donc oui, les langages actuels n'apportent pas de simplicité aux développeurs. Plus ils sont complexes, plus ils soulignent la vision limitée de leurs concepteurs : ces personnes ont déployé des prouesses pour fabriquer et poser une superbe échelle, mais elles se sont juste trompé de mur !

Et oui aussi, l'avenir va à la simplification. Mais ne vous en réjouissez pas : le jour où les outils permettront de définir les traitements logiquement et graphiquement, non seulement il faudra 'moins' de développeurs, mais il n'en faudra 'plus du tout'. En effet, définir un traitement de manière logique, c'est ce qu'on appelle le spécifier. Les Maîtrises d'OEuvres se videront, et les Maîtrises d'Ouvrages se rempliront. Au lieu de spécifier avec Word, les MOA spécifieront formellement avec un outil logique, avec plus de précision (par exemple beaucoup de Maîtrises d'Ouvrages ne 'spécifient' plus les rapports BO, c'est plus simple de les faire directement).

La simplification va être un très grand virage pour l'informatique. Elle va tirer le métier vers le haut, mais diminuer drastiquement l'activité. La satisfaction liée à la survenue de ce grand progrès aura donc un goût amer.

[I_believe_in_code]

On peut simplifier autant qu'on veut la façon de "requêter", il n'en reste pas moins que les SGBD eux-mêmes ne sont pas prêts d'être faciles à programmer.

On peut simplifier le développement de logiciel autant qu'on veut, mais ce sera toujours difficile d'écrire Photoshop ou Final fantasy 7.

[I_believe_in_code]

(...) la notion de pointeurs est pour moi aussi illogique et incompréhensible que du chinois remixé avec du javanais... (...)

Le C comme le C# et le C++ m'ont toujours apparu comme impossible à apprendre (pour mon cerveau en tout cas) pourtant j'ai vraiment envie de les connaitre et de les utiliser...

Alors est-ce que je n'ai jamais pu trouver un bon professeur ou tuto pour me l'enseigner de façon à ce que j'y comprenne quelque chose ? ou bien est-ce que c'est véritablement le langage en lui-même qui est trop complexe ? Je pense plutôt la seconde réponse...

Un pointeur est une variable dont la valeur est une adresse. Point. Qu'y-a-til de si impossible à comprendre là dedans ? On peut ne jamais progresser si on mets ses propres difficultés sur le dos des profs ou des langages eux-mêmes.

[gangsoleil]

à mon avis les langages 'physiques' ne sont pas l'avenir, nous devrions progressivement voir apparaître des langages 'logiques' graphiques beaucoup plus simples.

Ce que tu dis n'es pas denue de sens, pour une categorie de developpement : celle qui n'a que peu besoin de performances, ou qui n'a globalement que peu de contraintes. En gros, tous les logiciels pour lesquels, en cas de probleme de performance, on te repond "c'est pas grave, on changera la machine".

Maintenant, il existe une branche de plus en plus developpee, qui est l'embarque. Alors je ne pense pas ici aux jeux-video sur smartphone, mais bien aux logiciels qui s'executent dans des environnements contraints (voiture, avion, fusee, ...), avec des puissances de calculs (tres) limitee (satellite), des batteries que l'on veut faire durer (capteurs dans la nature, ...), etc.
Et pour tout ca, les langages "logiques" (pour reprendre ton vocabulaire) sont une immense perte, donc on va rester aux langages "physiques", ce qui n'est pas pour me deplaire

[micka132]

@cap_gregg
Le problème existera toujours quand on va vouloir sortir des sentiers battus, et qu'un gars veut un bouton bleu alors qu'il n'est possible que d'avoir du rouge[...].

[deathness]

Un pointeur est une variable dont la valeur est une adresse. Point. Qu'y-a-til de si impossible à comprendre là dedans ? On peut ne jamais progresser si on mets ses propres difficultés sur le dos des profs ou des langages eux-mêmes.

Je vois pas vraiment la grande difficulté à comprendre ça non plus. Une fois que tu t'es amusé un peu à les manipuler ça passe comme dans du beurre.

Et effectivement pour des trucs critiques comme les satellites, la puissance de calcul et la performance sont extrêmement important pour l'utilisation de l'énergie.

[Bousk]

Ce que tu dis n'es pas denue de sens, pour une categorie de developpement : celle qui n'a que peu besoin de performances, ou qui n'a globalement que peu de contraintes. En gros, tous les logiciels pour lesquels, en cas de probleme de performance, on te repond "c'est pas grave, on changera la machine".

Maintenant, il existe une branche de plus en plus developpee, qui est l'embarque. Alors je ne pense pas ici aux jeux-video sur smartphone, mais bien aux logiciels qui s'executent dans des environnements contraints (voiture, avion, fusee, ...), avec des puissances de calculs (tres) limitee (satellite), des batteries que l'on veut faire durer (capteurs dans la nature, ...), etc.
Et pour tout ca, les langages "logiques" (pour reprendre ton vocabulaire) sont une immense perte, donc on va rester aux langages "physiques", ce qui n'est pas pour me deplaire

Et SQL, ou BO, c'est mignon, mais la machine elle ce qu'elle veut c'est du binaire, de l'assembleur.
Ce n'est pas parce qu'une couche est cachée qu'elle n'existe plus ou est amenée à disparaître.
Supprime la couche, et SQL on lui dit adieu.

[chaplin]

Et oui aussi, l'avenir va à la simplification. Mais ne vous en réjouissez pas : le jour où les outils permettront de définir les traitements logiquement et graphiquement, non seulement il faudra 'moins' de développeurs, mais il n'en faudra 'plus du tout'. En effet, définir un traitement de manière logique, c'est ce qu'on appelle le spécifier. Les Maîtrises d'OEuvres se videront, et les Maîtrises d'Ouvrages se rempliront. Au lieu de spécifier avec Word, les MOA spécifieront formellement avec un outil logique, avec plus de précision (par exemple beaucoup de Maîtrises d'Ouvrages ne 'spécifient' plus les rapports BO, c'est plus simple de les faire directement).

La simplification va être un très grand virage pour l'informatique. Elle va tirer le métier vers le haut, mais diminuer drastiquement l'activité. La satisfaction liée à la survenue de ce grand progrès aura donc un goût amer.

En résumé, à force de tout simplifier, il suffira de regarder E=M6 et puis les chercheurs ne serviront plus à rien puisque la télé non explique tout.

Plus besoin d'aller chez le médecin, il suffit d'aller voir Docteur Internet puis de voir le médecin et lui dire qu'il est nul, ce dernier répondra gentillement, allez vous faire soigner par Docteur Internet, mais ne revenez plus chez moi par la suite pour vous plaindre ou vous faire soigner.

EDIT: le fond de ma pensée rejoint celle de Fernand Reynaud dans le skecth du boulanger:
[ame="http://www.youtube.com/watch?v=pNeuMzNre6E"]http://www.youtube.com/watch?v=pNeuMzNre6E[/ame]

[gangsoleil]

la machine elle ce qu'elle veut c'est du binaire, de l'assembleur.

Nous sommes bien d'accord. Mais en gros, la programmation de haut niveau, ca correspond a de l'abstraction de plus haut niveau, qui se traduit par de la generation de code.
Or cette generation de code est toujours moins optimisee que le code ecrit par l'humain, ce qui se traduit par une perte de performance, d'ou la necessite d'avoir des systemes plus puissants pour faire tourner du code equivalent.

Si tu essayes de programmer un "Hello World" en utilisant, par exemple, un middleware (Corba ou un autre, peu importe), tu t'apercevras que l'executable (s'il embarque le code dont il a besoin) est beaucoup plus gros (quelques dizaines de mega pour un hello world avec ACE par exemple, contre a peine quelques kilos dans des langages de developpement classique).
Dans certains cas (ceux que je cite dans mon precedent message par exemple), cela s'avere problematique, et donc cette surcouche logicielle n'est pas utilisee. Par contre, dans d'autres cas ou la machine n'est pas limitante, il peut etre tres interessant de developper avec un middleware, ce qui permettra de gagner en temps de developpement.

[Bousk]

Tout à fait, mais je faisais surtout remarquer que c'est absolument impossible que le bas niveau disparaisse, quand bien même une armée d'incapables ne travailleraient plus qu'en haut niveau. Comme le suggère le post plus haut.
Parce que le haut niveau est totalement dépendant du bas niveau, et ne peut pas exister tout seul, contrairement au bas niveau.

[el_slapper]

Tout à fait, mais je faisais surtout remarquer que c'est absolument impossible que le bas niveau disparaisse, quand bien même une armée d'incapables ne travailleraient plus qu'en haut niveau. Comme le suggère le post plus haut.
Parce que le haut niveau est totalement dépendant du bas niveau, et ne peut pas exister tout seul, contrairement au bas niveau.

D'autant plus qu'un langage de haut niveau ne dispense pas d'avoir un minimum de talent.

Les besoins en termes de traitements de l'information(au sens large, de la compta à l'image, du son à la gestion de stock, du marketing à la sécurité) sont quasiment illimités. Le haut niveau est indispensable pour gérer les demandes les plus complexes. Pour autant, même en hypersimplifié, ça reste des demandes complexes, et du talent sera toujours nécéssaire, ne serait-ce que pour bien comprendre et formuler le problème.

Une armée d'incapables sera toujours une armée d'incapables. Le souci du haut niveau, c'est qu'ils peuvent faire illusion. En bas niveau, ils ont une segfault, ou je ne sais quelle horreur(je ne fais pas de C/C++, c'est là mon moindre défaut). Mais, au final, si on veut des choses qui fonctionnent, bas ou haut niveau, il faut des gens qui pigent. Pas des gens qui, en BO, renomment une colonne "agence" en colonne "agent", juste parcequ'ils ont la flemme de chercher la colonne "agence"(vécu. Une semaine de réparation pour ma voisine).

Le haut niveau est inévitable dans pas mal de domaines, pour sa capacité à accélerer le développement de systèmes complexes. Il ne se substitue pas à l'intelligence. Il la magnifie, mais seulement si elle est présente.

[deadalnix]

Ce que tu dis n'es pas denue de sens, pour une categorie de developpement : celle qui n'a que peu besoin de performances, ou qui n'a globalement que peu de contraintes. En gros, tous les logiciels pour lesquels, en cas de probleme de performance, on te repond "c'est pas grave, on changera la machine".

Sauf que la loi de Moore, c'est fini. Enfin, plus précisément on arrive toujours à doubler le nombre de transistors, mais on n'arrive plus, pour diverses raison physique, à transformer ces transistors en puissance de calcul.

D'où le regain d'intérêt pour les langages natifs qu'on observe ces dernières années.

[deathness]

Sauf que la loi de Moore, c'est fini. Enfin, plus précisément on arrive toujours à doubler le nombre de transistors, mais on n'arrive plus, pour diverses raison physique, à transformer ces transistors en puissance de calcul.

D'où le regain d'intérêt pour les langages natifs qu'on observe ces dernières années.

Pas si finie que ça... De nouvelles technos se basant sur de tout nouveaux concepts (pour le marché grand public j’entends) devraient pas tarder à pointer leur nez d'ici 5 ans et à prendre même de l'avance sur cette "loi".

[deadalnix]

Je ne sais pas si je dois croire plus quelqu'un sur un forum qui ne cite aucune source, ou Facebook, Google, Microsoft, AMD, nVidia et Intel.

Tu en penses quoi ?

[Bluedeep]

Sauf que la loi de Moore, c'est fini. .

Laquelle ?

il y a 3 expressions de la loi de Moore qui ont toutes étaient plus ou moins distordues dans le temps, de tel sorte que parler de loi de Moore actuellement, c'est plus que flou.

EDIT : il y a un article sur Wikipedia sur le sujet qui est pas trop mal fait : http://fr.wikipedia.org/wiki/Loi_de_Moore