Faut-il simplifier la programmation et revoir ses fondements ? Un journaliste s'essaie au développement et dénonce sa complexité

Le 15/06/2011, par Idelways, Coordinateur publications
De toute évidence, maîtriser un langage de programmation raisonnablement populaire, aussi complexe soit-il, ne peut être en aucun cas comparé à la difficulté d'apprendre une langue naturelle.

Pourtant, des personnes qui se lancent dans le développement trouvent énormément de difficultés à prendre leurs marques, et se sentent exclues dans une ère où les applications sont fondamentalement au coeur de nos vies. Où « le code s'élève à l'importance de l’alphabétisation ».

Chris Tompkins est un consultant journaliste qui vient de vivre l'une de ces expériences qui poussent certains à remettre en question leurs capacités intellectuelles et prédispositions naturelles pour un domaine qui leur est étranger, tout en scellant dans l'oubli le souvenir de cette tentative.

Mais pas lui !

Chris Tompkins rejette plutôt la faute sur les concepteurs des langages de programmation et remet en question tout le fondement du domaine tel qu'on les connaît.
Il estime que les inventeurs insèrent délibérément de la complexité dans les langages pour flatter leur propre ego, aux dépens des personnes (les enfants notamment) que cette complexité éloigne chaque jour du monde du développement.

Malgré une maîtrise du JavaScript qu'il estime suffisante, sa tentative récente d’apprendre l'Objective-C l'a mis devant un constat pour lui révoltant : « c'est bien trop dur », s'écrit-il sur un billet de blog qui remue actuellement la blogosphère anglophone.

Chris Tompkins est certainement au fait qu'il existe des langages de haut niveau, conçus pour rendre les développeurs plus heureux ; de ceux qui permettent d'écrire des DSL (langages dédiés) à d'autres, encore immatures, qui proposent de programmer en langage (presque) naturel.

Seulement, le coup de gueule de Tompkins s'abat précisément sur le langage C inventé il y a 40 ans, une référence ayant inspiré un tas d'autres langages populaires.

Le C est à la base de l'Objective-C, qui le complète et permet de mixer dans le même code des instructions issues des deux mondes. Un langage plébiscité par Apple, notamment pour le développement natif pour Mac OS et iOS.

Notre journaliste mécontent a souhaité écrire une application iPhone (où seuls les langages natifs sont autorisés), probablement pour satisfaire un besoin personnel. Il n'arrive pas à concevoir que la barrière pour y arriver soit aussi élevée.
Car après tout, on n'est jamais mieux servi que par soi même, même en développement.

Pour expliquer son point de vue, Tompkins propose une analogie décalée et probablement exagérée, mais intéressante : programmer en C revient d'après lui à connaître le génome des ingrédients alimentaires pour pouvoir les utiliser dans son petit repas !

Il se demande pourquoi ne pouvons-nous pas coder comme on fait pour cuisiner ? Comme quand on part choisir les plus belles tomates au supermarché du coin, les utiliser sans se soucier de comment, ni de quoi sont-elles réellement faites.

Les bibliothèques, frameworks et autres bases de codes, qui mettent à la disposition des développeurs des millions de lignes de code prêtes à entrer en action, ne suffisent pas d'après Tompkins qui plaide pour la création d'un langage à syntaxe naturelle qui formera une base plus simple pour l'apprentissage de la programmation.

Bref, il conclut son billet fort polémique en plaidant pour la simplification du code, comme un geste de « charité » envers ses semblables, au risque « d'empêcher des milliers, voire des millions de voix, d'arriver aux utilisateurs ».

Source : blog de Chris Tompkins

Et vous ?

Que pensez-vous de ce billet de Blog et de la position de son auteur ?
La programmation est-elle d'après vous plus complexe qu'elle ne devrait l'être ?

Les rubriques (actu, forums, tutos) de Développez


Poster une réponse Retrouver la discussion sur le forum

Avatar de DonQuiche DonQuiche
Membre Expert
le 17/10/2011
@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.
Avatar de Bluedeep Bluedeep
Expert Confirmé Sénior
le 17/10/2011
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.


Citation:





Envoyé par DonQuiche
Voir le message

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).
Avatar de BenoitM BenoitM
Membre Expert
le 17/10/2011
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
Avatar de Bluedeep Bluedeep
Expert Confirmé Sénior
le 17/10/2011

Citation:





Envoyé par BenoitM
Voir le message

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").


Citation:




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).


Citation:




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).


Citation:




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).
Avatar de BenoitM BenoitM
Membre Expert
le 17/10/2011
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é
Avatar de gangsoleil gangsoleil
Modérateur
le 17/10/2011

Citation:





Envoyé par BenoitM
Voir le message

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.
Avatar de Bluedeep Bluedeep
Expert Confirmé Sénior
le 17/10/2011

Citation:





Envoyé par BenoitM
Voir le message

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.


Citation:




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 ..


Citation:




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.


Citation:




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


Je ne connais pas MySql.
Avatar de dewind dewind
Membre régulier
le 18/10/2011
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 ?
Avatar de BenoitM BenoitM
Membre Expert
le 18/10/2011

Citation:




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
Avatar de dewind dewind
Membre régulier
le 18/10/2011
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.
 
 
 
 
Partenaires

Hébergement Web