Le blog d'un geek devenu directeur technique

Les langages de programmation – Partie 1 : Ce que je connais

Régulièrement (enfin, disons tous les 3/4 ans) je me pose des questions existentielles au sujet des langages de programmation. Pourquoi est-ce que j’aime tel langage, pourquoi je déteste tel autre, qu’est-ce que je pourrais vouloir et que je n’ai pas, et ainsi de suite…

Ne me demandez pas pourquoi, mais ça me reprend en ce moment. Ça va sûrement repartir aussi vite que c’est venu, mais ça amène quand même quelques réflexions.

Je pense écrire 3 articles sur le sujet. Dans celui-ci, je vais lister les langages que je connais, histoire de situer un peu les choses. Dans le suivant, je parlerai un peu du modèle objet sous un angle inhabituel. Pour terminer, je « réfléchirai à haute voix » sur ce que j’attends d’un langage de programmation, et pourquoi je serai toujours un éternel insatisfait.

BASIC

C’est le premier langage que j’ai appris. Quand j’étais gamin, dans les années 80, il y avait deux émissions télévisées au Québec − Octo-puce et Octo-giciel − qui enseignaient entre autre à programmer en Basic. C’est comme ça que j’ai commencé à programmer sur papier en rêvant au jour où j’aurais un ordinateur. Environ 10 ans plus tard, j’ai passé un couple d’années à programmer en Visual Basic ; c’était avant de commencer mes études d’informatique, et je croyais savoir programmer…

Ce que j’en retiens, c’est que le Basic, le « vrai » (celui des Apple II et Commodore 64) était en fait complètement imbitable. Après coup, j’ai compris en partie pourquoi Dijkstra avait la dent si dure à son encontre.
Malgré tout, ses déclinaisons successives, depuis le QuickBasic, les STOS et AMOS, jusqu’au RealBasic et le VB.NET, en ont fait un langage moderne et utilisable.

Moderne et utilisable, mais je n’ai désormais strictement aucune envie de coder en Basic.

Javascript

Je me suis intéressé au Web dès 1995. Je me suis mis alors au HTML, et même à cette époque cela incitait à rapidement se pencher sur le Javascript. Les premières années, je n’en ai fait qu’un survol, mais j’ai fini par mettre en œuvre des techniques assez poussées (notamment concernant la programmation orientée objet en Javascript) qui me sont encore utiles aujourd’hui au quotidien. Je suis même passé par une phase de développement assez intensive à base de XUL, où tout le code est réalisé en Javascript.

À une époque, j’étais assez fan du Javascript. J’aimais sa simplicité et sa malléabilité. J’ai imaginé l’utiliser pour des usages très divers. Pour les développements « client lourd », après avoir développé en XUL, j’en suis un peu revenu ; comme expliqué dans un précédent article, je me suis fatigué de devoir taper 8 lignes de code illisible pour simplement lire le contenu d’un fichier. Pareil pour les développements côté serveur ; j’ai longtemps pensé que le Javascript combinait assez de qualités pour s’y montrer à son avantage ; cette idée va et vient, depuis le serveur de Netscape dans les années 90, jusqu’à  des projets comme CommonJS et Node.js.
J’espère que Mathieu ne m’en voudra pas, mais l’ensemble du langage me paraît maintenant trop bancal pour sortir de l’usage Web client qui est sa spécialité. Entre le modèle objet incomplet, la bibliothèque standard plutôt limitée et une évolution très lente (qui ne laisse pas apercevoir d’améliorations profondes à courte échéance), je préférerai toujours d’autres solutions.

C

Ce fut la grande révélation de ma vie. Ce que j’apprécie dans ce langage, c’est sa simplicité et sa limpidité. Quelques types scalaires, des structures (et des énumérations et des unions), des fonctions… et des pointeurs au milieu de tout ça. Difficile de faire plus évident. J’ai acquis une certaine expertise en C ; durant mes études j’ai fait du développement kernel (Linux et BSD), et par la suite j’ai travaillé dans le développement système et réseau. C’est formateur.

On entend souvent dire que le C n’est qu’un assembleur à peine amélioré… C’est tellement faux ! Par contre, ce qui est certain, c’est qu’il est quasi-impossible de faire des exécutables plus rapides et plus petits que ceux écrits en C. Bon, il n’est évidemment pas exempt de défauts, mais qui sont inhérents à ce qu’il est intrinsèquement. Si vous savez ce que vous faites, le C est un outil redoutable ; par contre, si vous vous permettez des approximations, vous ne vous en relèverez pas.

Aujourd’hui, je ne code plus du tout en C, au profit du PHP (j’en parle juste après). Cela m’ennuie un peu, le manque de pratique émousse le niveau d’expertise que j’avais ; mais d’un autre côté, si on peut coder plus vite sans avoir besoin des performances maximales…

Perl

J’ai appris les bases du Perl durant mes études d’informatique. Comme disait mon professeur d’administration système (Marc Espie, l’un des principaux contributeurs à OpenBSD), “il faut savoir laisser son compilateur au placard quand on a juste besoin d’un petit script”. Plus tard, j’ai travaillé pendant 4 ans dans une entreprise où le Perl était le principal langage de développement ; j’y ai considérablement amélioré ma connaissance du langage.

J’ai apprécié ce langage, qui est particulièrement souple et puissant. Il intègre nativement les listes, les tableaux associatifs et les expressions régulières, ce qui est très pratique au quotidien. Le CPAN est un fantastique outil centralisé pour trouver des bibliothèques, tellement complet qu’il est difficile à mettre en défaut.

Par contre, j’ai aussi été profondément gêné par les bizarreries du langage. La syntaxe qui autorise d’écrire certaines choses « à l’envers ». La notion de référence qui casse les noix quand on manipule des types scalaires (c’est comme des pointeurs… mais ça n’a rien à voir). Les variables magiques (on aime ou on déteste, moi je ne suis pas fan). Le modèle objet est incomplet bien que largement utilisable. Mais surtout, c’est un langage qui incite presque à faire du code illisible, tellement il permet d’écrire les choses de plusieurs manières différentes ; si vous n’êtes pas vigilant, vous finissez par privilégier les écritures les plus denses mais les moins maintenables.

PHP

J’ai commencé à utiliser le PHP dans sa version 3 en 1999. Pendant plusieurs années j’alternais mes développement serveur entre le PHP et le C. J’ai fini par m’habituer aux qualités du PHP, sa simplicité et sa bibliothèque très fournie. Sa syntaxe très inspirée de celles du C et du Perl me convenait très bien, et j’ai fini par me rendre compte que recompiler un exécutable à chaque modification d’un site web, c’est quand même pénible.

J’ai suivi les évolutions successives du langage, à travers ses versions majeures (4, 5, 5.3) et les différentes améliorations qu’elles ont apportées. J’apprécie le PHP pour sa souplesse et son équilibre entre contrainte et permissivité. Syntaxiquement, son intégration des tableaux associatifs est particulièrement réussie, et son modèle objet est complet depuis 2004 (version 5).

La quasi-totalité de mes développements se font désormais en PHP. J’ai réalisé quelques projets assez pointus avec ce langage (FineFS, Temma), et je suis très heureux de profiter des facilités qu’il offre.

C++

J’ai fait du C++ à l’école, je l’ai même utilisé pour développer un projet sous licence libre (Headerbrowser). C’est un langage très puissant, qui comble la plupart des lacunes du C, tout en gardant une syntaxe très similaire (au contraire de l’ObjectiveC, par exemple).

Malgré tout, je me suis toujours senti « le cul entre deux chaises » avec le C++. Si j’ai un grand besoin de performance ou de portabilité, j’aurai tendance à choisir le C pour sa simplicité. Si je cherche un langage de haut niveau, je prendrais le PHP pour son typage faible et sa gestion dynamique de la mémoire. Certaines fonctionnalités du C++ complexifient la syntaxe à l’extrême. Nul doute que cela ne soit qu’une question d’habitude, mais je n’arrive pas à m’y faire.

J’ai parfois hésité à écrire du code C++ comme si je codais en C, en utilisant seulement les fonctionnalités qui m’intéressaient (les objets et les exceptions, par exemple). Mais j’ai lu tellement de choses disant que c’est une mauvaise idée… Je vais peut-être revenir là-dessus, parce que les donneurs de leçon qui disent que tel ou tel truc, « il faut le faire à fond ou pas du tout », j’ai fini par ne plus les écouter.

Java

J’ai appris le Java durant mes études d’informatique. Pour quelqu’un qui s’orientait vers le développement système, ce langage ne jouissait pas d’une bonne réputation.
Je l’ai au final très peu utilisé en dehors du cadre académique. Dans toute ma carrière, je n’ai qu’une expérience d’un an en JEE.

J’ai trouvé que le Java était un plutôt bon langage. Sa grande force vient de sa bibliothèque standard d’objets, qui est très complète et très proprement structurée. J’ai par contre connu des problèmes avec l’environnement général, pas évident à mettre en place au premier abord.

Dans le cadre du développement Web, j’ai trouvé le JEE d’une lourdeur incroyable. L’ensemble des technologies impliquées est vaste et complexe. À mon sens, inutilement vaste et complexe. Beaucoup de choses semblent séduisantes d’un point de vue théorique, mais leur utilisation est malaisée, ce qui allonge les temps de développement et les coûts associés.

Au final, j’ai un peu les mêmes griefs que pour le C++. Pour un langage qui se veut de haut niveau, il lui manque beaucoup de facilités d’écriture, tout en manquant de clarté sur plein de points. S’il fallait faire un match en C++ et Java, je les mettrais ex æquo. Le Java me semble plus clair, et son API standard est ultra-complète ; par contre, le C++ est plus dans mes habitudes par son absence de machine virtuelle et sa compatibilité avec le C (aussi bien le code que les bibliothèques compilées).

Fortran

J’en parle juste pour déconner. J’ai fait un peu de Fortran quand j’étais en fac de biologie. Je n’en garde presque aucun souvenir. Il n’empêche que ce langage a continué à évoluer, qu’il est toujours beaucoup utilisé dans la communauté scientifique, et que c’est l’un des langages les plus facilement optimisable sur des architectures réparties (il n’y avait pas d’allocation dynamique de la mémoire jusqu’au Fortran90).

Pascal

Là aussi, j’en parle juste pour le fun. Quand j’étais petit et que je commençais à m’intéresser à l’informatique, un ami informaticien qui avait fait le MIT m’a donné un livre traitant de la programmation en Pascal. Je n’y ai pas compris grand chose sur le moment. Bien plus tard, alors étudiant en informatique, je me souviens avoir aidé des amis qui étaient en prépa, et qui bûchaient sur de la programmation en Pascal. J’ai pu comprendre sans problème les bases du langage en quelques secondes. Et j’ai compris de quoi mon prof de C parlait, lorsqu’il évoquait les différences entre les langages créés par les mathématiciens suisses et ceux créés par les hippies américains. Niveau syntaxe et clarté, pas de soucis, je préfère les baba-cools.

Lisp et OCaml

Oui, je continue avec les trucs à la con. Juste pour la petite histoire, j’ai eu à développer un interpréteur de Lisp durant mes études. La syntaxe est tellement simple que ce type d’interpréteur n’est vraiment pas très compliqué à coder. Bon, de là à vouloir coder en Lisp au quotidien, c’est une autre paire de manches. À une époque, c’était une idée tout à fait valable quand on voulait intégrer un langage dans un logiciel, pour permettre d’écrire des extensions (comme dans Emacs, par exemple).

L’OCaml, je l’ai étudié durant mes études. Avec le Lisp et l’OCaml, je me suis vite rendu compte que j’avais beaucoup de mal à me faire aux langage fonctionnels (je sais, OCaml peut être considéré comme à la fois fonctionnel et impératif, mais zut). J’ai sûrement été trop marqué par les langages procéduraux, mais on peut quand même remarquer que les langages fonctionnels sont globalement l’apanage des chercheurs et des mathématiciens, alors que les langages procéduraux sont utilisés par « ceux qui veulent faire du vrai code » ; je forcis le trait, mais il y a un peu de vrai là-dedans.

Et pourtant, on peut voir l’héritage des langages fonctionnels se cacher dans le Javascript, ou dans des notions comme le map-reduce. Il est important de connaître le principe, même sans l’utiliser au quotidien.

Similar posts

19 Commentaires

  1. 8 janvier 2012    

    Je reviendrai juste sur ta conclusion :

    La programmation fonctionnelle revient également en force avec Scala ; les routines de gestion de liste, les écritures de fonctions récursives (linéarisées par le compilateur) et les grands principes d’immuabilité.

    Il y a pas mal de frameworks orientés web pour ce langage, même si ce n’est pas trop l’utilisation que j’en fait ils semblent assez matures.

  2. Gus's Gravatar Gus
    8 janvier 2012    

    Vous avez donc étudié beaucoup de langages de programmation. Vous n’évoquez pas Ruby. N’avez-vous jamais développé avec Ruby-on-Rails ?

  3. 8 janvier 2012    

    @Adrien : Effectivement Scala a réussi à faire parler de lui. Il est encore difficile de savoir si c’est une reconnaissance de ses qualités ou un vrai mouvement qui va en faire un langage d’importance. Parce que pour le moment, j’ai l’impression que c’est plus un succès d’estime qu’une véritable utilisation concrète à grande échelle.
    Si Scala ne passe pas à l’échelle supérieur, ce sera un peu comme le Smalltalk : tout le monde dit que c’est pétri de qualités, mais personne ne l’utilise vraiment.

    Je m’y suis intéressé, et j’ai du mal aussi bien avec la logique qu’avec la syntaxe…

  4. 8 janvier 2012    

    @Gus : J’ai regardé le Ruby de près, et j’ai étudié le Ruby on Rails. Je ne l’ai pas listé comme un langage que je connais, parce que si je l’ai étudié, je n’ai jamais codé en Ruby.
    De manière générale, j’ai beaucoup de mal à me faire à la syntaxe du Ruby. Mais cela ne retire rien aux qualités qui en font l’un des langages les plus utilisés actuellement. Ça veut juste dire qu’il ne me convient pas.

  5. 9 janvier 2012    

    « il faut le faire à fond ou pas du tout » : tout dépend de l’expérience de celui qui annonce cela ;).
    Sinon, je suis surpris que tu n’es pas accroché à Ruby avec une telle expérience en Perl.
    En effet, les deux me font le même effet, au niveau de la syntaxe, et je n’arrive pas à m’y faire, malgré leur qualité respective.
    Au final, j’ai un parcours assez similaire au tien, soit basic, turbot pascal, C++, C (oui, j’ai fais les choses à l’inverse, et donc je peux te dire que faire du C en C++ est une mauvaise idée :)) et enfin PHP et les langages qui le complète comme Javascript, SQL, html, xml, etc.
    Et depuis 12 ans, à part quelques excursions très ponctuelles vers Perl ou Ruby, je n’ai plus rien appris, et parfois je le regrette, la faute à une vie de famille et des projets personnels qui ne me laisse pas le temps d’apprendre à nouveau, et surtout à PHP.
    En effet, je ne suis pas encore tombé sur un problème que je ne peux pas résoudre de manière satisfaisante (et non optimale, attention à la nuance) avec PHP.

  6. 9 janvier 2012    

    « il faut le faire à fond ou pas du tout » : tout dépend de l’expérience de celui qui annonce cela ;) .

    Moui, mais tu connais mon amour des extrêmes :-)
    Pour moi, dès qu’il s’agit de mettre un curseur quelque part, la réponse est rarement de le placer complètement à un bout ou à l’autre. C’est forcément plus nuancé.

    Concernant Ruby et le Perl, je suis étonné de ta remarque. Je ne leur trouve pas la moindre ressemblance dans leurs syntaxes. Le Perl reprend beaucoup de choses du C (je parle de la syntaxe, pas forcément de la « philosophie »), et il a eu beaucoup d’influence sur le PHP. Alors que le Ruby… j’ai beau essayer régulièrement, ça entre pas.

    Écrire du C en C++, là encore, je pense qu’il y a des cas où ça peut fonctionner très bien. Cela revient à « ajouter du sucre » sur le C, faire du code procédural mais en manipulant des objets quand cela facilite les choses. Je ne dis pas qu’il faut chercher à coder de cette manière en général ; mais ça s’applique plutôt bien dans certaines situations. C’est un peu pareil en PHP, d’ailleurs : ce n’est pas parce qu’on fait un petit programme procédural qu’on ne veut pas utiliser le moindre objet, ou qu’on veut se passer des exceptions.

    Je ne dis pas que c’est ton cas, mais j’ai souvent vu des développeurs ayant fait du C++ sans avoir d’abord pris le temps de bien connaître le C. Résultat, il y avait des principes fondamentaux qu’ils ne maîtrisaient pas du tout parce qu’ils avaient toujours pu les contourner en C++ (pointeurs, pointeurs sur fonctions, savoir ce qu’il se passe en mémoire, différence entre structure/union/énumération, etc.). Pour ce genre de personne, il vaut mieux en rester au C++ et ne pas mélanger avec du C, c’est certain.

    Pour finir, je partage avec toi l’utilisation du PHP, allant jusqu’à faire avec des trucs assez bas niveau. Il y a un cas où il ne montre ses limites, c’est lorsqu’on a besoin de faire des calculs intensifs. Je prépare d’ailleurs quelques benchmarks intéressants. Un ami qui fait des jeux sur le web m’a dit que pour le calcul des coups possibles d’une IA, son programme en PHP pouvait analyser quelques centaines de coups à la seconde, là où le même algorithme en Java en calculait des dizaines de milliers. Ils ont gardé la version Java.

  7. 9 janvier 2012    

    Pour la « ressemblance » entre la syntaxe de Ruby et celle de Perl, je parlais de l’aspect « capilotracté » ;).
    Pour le C++/C, j’ai eu la chance de faire mes armes avec des fans du bas niveau (merci l’IUT et ses vacataires issus de l’industrie), donc je suis passé à côté de cette embuche.
    Par contre, j’ai vu des programmeurs C de très bon niveau écrire du très mauvais C ++ parce qu’ils ne prenaient pas en compte l’aspect objet de C++.
    Et oui, PHP est très mauvais sur les calculs en virgule flottante ( 5.4 améliore un peu les choses, mais on est loin de l’efficacité d’un java ou autre).
    Je me souviens d’un calcul de cuverie (en gros calculer le pourcentage de tel ou tel vin dans une cuve après n mouvements sur la cuve, donc une bête histoire de prorata) prendre presque 5 minutes en PHP 4 là ou le même programme en C mettait 5 ms…
    Dans ce contexte, le seul avantage, mais non des moindres, de PHP est qu’il permet de prototyper très rapidement du fait de sa simplicité.
    L’implémentation dans un langage plus performant est ensuite beaucoup plus facile.

  8. 9 janvier 2012    

    Pour la « ressemblance » entre la syntaxe de Ruby et celle de Perl, je parlais de l’aspect « capilotracté » ;) .

    Ah oui, vu sous cet angle, je suis assez d’accord. Le Perl peut être très lisible, mais − comme je le disais dans l’article − il pousse un peu au crime.

    Par contre, j’ai vu des programmeurs C de très bon niveau écrire du très mauvais C ++ parce qu’ils ne prenaient pas en compte l’aspect objet de C++.

    Arf, c’est tellement vrai ! :-)

    Dans ce contexte, le seul avantage, mais non des moindres, de PHP est qu’il permet de prototyper très rapidement du fait de sa simplicité.
    L’implémentation dans un langage plus performant est ensuite beaucoup plus facile.

    Oui, tu as raison.
    Je me souviens de l’époque (jusqu’au milieu des années 90 à peu près) où les langages interprétés étaient systématiquement trop lents pour être utilisés à grande échelle. Ils étaient alors cantonnés à 2 rôles : le prototypage rapide d’applications (qui étaient ensuite redéveloppées en C ou C++), et l’utilisation comme « langage de glue » qui se contentait de faire le lien entre des modules métiers compilés nativement.
    Je ne regrette pas du tout cette époque ;-)

  9. Un ami qui vous veut du bien's Gravatar Un ami qui vous veut du bien
    10 janvier 2012    

    (Oui, je reponds ca l’envers sur tes posts, c’est normal, je suis en notation polonaise inversee)

    Concernant Perl : je n’ai jamais pu me faire ca la syntaxe objet de Perl. Cela dit, il existe désormais Moose qui n’a rien ca voir avec ce que j’ai connu quand j’avais tenté de m’y mettre (pas faute d’avoir lu plusieurs fois perlboot et ses copains pourtant…). J’aime BEAUCOUP les « syntaxes inverses », qui peuvent (je trouve) rendre certains codes bien plus lisibles (tant qu’on abuse pas trop non plus).

    Concernant le lien entre Ruby et Perl : je les trouve très forts au contraire, et même si la syntaxe diffère entre les deux langages, la volonté de laisser une grande liberté d’expression au programmeur me semble évidente dans le cas de Ruby comme Perl. D’ailleurs on retrouve les expressions conditionnelles « inverses » de Perl, et Matz dit clairement qu’il s’est inspiré de Perl pour concevoir Ruby.

    Concernant la prog fonctionnelle en règle générale, elle est bien plus utilisée que ce que les gens imaginent. Perl lui-même propose pas mal d’opérateurs « fonctionnels » (avec ou sans effets de bord) : map et grep sont de parfaits exemples. En C# aussi il y a eu beaucoup d’ajouts de constructions fonctionnelles. L’inférence « efficace » de types en POO vient en partie de l’influence des langages « majoritairement » fonctionnels tels LISP/Scheme, OCaml, etc. L’utilisation de fonctions anonymes et de fermetures, bien que pas réservée aux langages fonctionnels, y est apparue en premier si je ne me trompe pas — les trucs du genre :

    sub foo { my ($first,$second) = @_; return $first * $second; }
    # ...
    my $val = 10.243;
    my $specialized = sub { foo($val,shift) };
    map { print $specialized($_) } (1 .. 10);

    Une dernière précision : Common LISP et OCaml sont tous deux multi-paradigmes. ;-) Si tu veux du « fonctionnel pur » il faut regarder du coté de Erlang par exemple (qui est déclaratif et fonctionnel pur : pas de boucles, juste des récursions !)

    Concernant C++, j’aimerais savoir ce que tu appelles coder du C en C++. :-) De façon générale, C++ est lui aussi multi-paradigmes (et maintenant qu’il inclut aussi les lambda dans la spec, il commence aussi à toucher au paradigme fonctionnel). Et l’objectif du C++ a été depuis le début de ne payer que ce qu’on utilise, donc ne vouloir utiliser que « C-avec-classes » (par exemple) et la STL est à mon avis un bon compromis. Mais faire du C-avec-templates-et-pas-de-classes est aussi très bien selon moi : on peut implémenter de très bonnes fonctions génériques avec d’excellentes performances de cette façon.

  10. 10 janvier 2012    

    @ami : Pour le Perl, tu m’étonnes ; on a bossé ensemble sur de gros projets en Perl (OK, ça fait 8 ans, mais n’empêche !), et je n’ai pas souvenir que tu ais eu le moindre problème avec le langage. Sûrement parce que je mettais un point d’honneur à ce qu’on écrive du code lisible ? ;-)

    Je sais que les langages fonctionnels sont plus répandus qu’on ne le pense. Je dis bien dans mon article qu’on en retrouve des éléments déguisés un peu partout, et souvent parmi les concepts les plus pointus (cf. l’exemple du MapReduce).

    Enfin, quand je parle de code du C en C++, ça veut dire écrire du code globalement procédural, mais qui appelle des objets là où ça a du sens. On peut voir ça comme un découpage du code métier en différentes bibliothèques (des objets propres, qui cachent leur implémentation et offrent une API claire), avec du code procédural qui fait la glu au milieu de tout ça.

  11. 16 janvier 2012    

    Pour perl (qui est mon langage preferé) le modele objet est en effet pas terrible. Il faut une grosse discipline pour ne pas faire n’imp. Dans mon équipe (ou le niveau est très bon) le code est super lisible et « aux normes », comparable à du java on va dire, dans d’autres équipes c’est l’horreur. Moose, que je n’ai pas encore mis en oeuvre, semble aussi complètement regler la majorité des problèmes.

    Par contre un truc qui m’agace c’est qu’on parle toujours de la capacité de perl a devenir illisible… Serieusement 90% du code de ma boite est du java et ya des gens qui ecrivent vraiment des bouses indéchiffrables en java… Bref pour moi quelqu’un de bon ecrira proprement quel que soit le langage, quelqu’un de moyen cradera surement plus rapidement le perl, mais cradera aussi n’importe quel autre langage.

    Ruby j’ai bien aimé, je trouve qu’en général le code est très clean, très joli a regarder… mais trop lent.

    PHP pas pratiqué depuis 10 ans.

    Je me suis remis à C, mais pour la majorité de ce que je fais, c’est trop long à coder. Cela m’a servi juste une fois recement pour un truc très intensif en calcul. Je trouve pourtant que c’est vraiment très important de travailler le C pour bien comprendre comment fonctionnent les trucs bas niveau.

    J’ai un peu fait d’Objective C pour rigoler, il y a des trucs très bien, le modele objet est assez bien foutu et très rapide à coder, mais par contre je trouve que le code a vraiment une tronche étrange, difficile à lire même quand c’est bien écrit. Bref, pas fan.

  12. 16 janvier 2012    

    oh en passant, sur les langages fonctionnels. J’ai bcp de mal a m’y faire aussi mais j’ai lu quelque part que les gens commencant la programation, n’ayant jamais eté exposés à du langage procédural, trouvaient ca plus naturel. J’ai un peu du mal à y croire, j’avoue, mais why not.

  13. 16 janvier 2012    

    @Loïc : Oui, je sais qu’on peut faire du Perl très lisible, tout comme on peut faire du Pascal très crado. Mais il n’empêche que certains langages facilitent les conventions d’écritures alors que d’autres proposent tellement de moyens différents pour arriver au même résultat que ça peut devenir difficile à suivre.
    D’ailleurs, durant les 4 années pendant lesquelles nous avons codé en Perl dans la même entreprise, je me souviens de certains bouts de code pas toujours évidents à décrypter…

    Je n’ai jamais essayé Moose, mais sa seule existence montre les lacunes de Perl 5. Je ne sais pas ce qu’il en est pour Perl 6.

    Le Ruby, j’ai vraiment du mal. Et je te rejoins sur l’Objective-C, la syntaxe est particulièrement étrange (alors qu’il se réclame héritier direct du C, ce qui n’est absolument pas le cas).

    J’ai lu la même chose que toi concernant les langages fonctionnels. Je suis dubitatif, moi aussi, même s’il y a sûrement un fond de vérité.

  14. Oelita's Gravatar Oelita
    19 janvier 2012    

    Ah, dans ma jeunesse étudiante, j’ai fait du Prolog en plus du Lisp, c’était rigolo :-)
    Après, j’ai fait du Turbo-Pascal et du dbase3. Puis (1991) du Clipper qui était un dérivé de dBase, avec les mêmes fichiers de données en DBF, pas SQL. C’était assez sympa, franchement, Clipper, il y avait déjà de l’objet dedans, un chouïa. Pour faire développer sous DOS, c’était pas mal du tout (mieux que cet affreux Clarion qu’on a tenté de me faire gober).
    J’ai ensuite fait du Easel sous OS/2, un langage IBM, événementiel mais pas objet du tout, une vraie horreur pour construire un framework avec des passages de paramètres immondes pour du procédural.
    Je suis passée à PowerBuilder en 1995, et franchement, j’ai adoré. C’est un environnement de développement complet, et qu’est-ce qu’on codait vite une appli de gestion client-serveur, avec ça ! Efficace en diable pour ce qui était 95% des applis d’une boite standard, fastoche pour mettre en place un référentiel commun.
    Après, internet est arrivé en force, et j’ai appris le PHP en v3 comme toi, en solo pour me construire un site perso, et j’ai trouvé ça cool. Au boulot, par contre, on m’a collé Java J2EE, et c’est resté coincé, j’ai fait une allergie totale. Lourd comme c’est pas permis. Très difficile à intégrer pour les développeurs un peu anciens qui venaient de PowerBuilder ! Du coup, j’ai lâché le dev au boulot, et j’ai continué en PHP pour mes trucs persos. Je touche un peu au Javascript sans m’y plonger.

  15. 20 janvier 2012    

    Prolog, Lisp, Clipper, Easel… Quelle chance ! ;-)

  16. 26 février 2012    

    Exceptionnellement, je ne ferai pas la tête parce qu’on critique JavaScript ;)
    Pour le coup, les arguments que tu avances sont justifiés et réels. Il est vrai que le langage n’avance malheureusement pas aussi vite que ce monde qu’est le nôtre. Les bidouilles sont du coup assez nombreuses pour faire parfois des trucs devenus incontournables.
    Ceci dit, la donne est en train de changer avec HTML 5, de nouvelles API sont disponibles et waouh, il y a vraiment un paquet de belles choses là dedans.
    Article intéressant en tout cas.
    Pour rejoindre le principe de l’article, on peut compter à mon actif : PHP, JS (ah bon ? :p), Java, C#, Pascal et Ada. J’ai fait pas mal de C/C++ mais à contre-coeur, c’est vraiment pas mon truc ces deux langages, je préfère oublier être passer par ça…

  17. 26 février 2012    

    @Mathieu : Quand je critique le Javascript, c’est principalement pour le développement serveur ou « client lourd », mais c’est une chose qui dépend plus de l’environnement que du langage lui-même (cf. ma comparaison entre XUL et PHP). Pour le développement Web, ça peut aller (surtout avec une bonne dose de jQuery). Bon, on aurait un modèle objet permettant d’avoir une visibilité publique/protégée/privée, ce serait quand même vachement bien… (mais c’est valable aussi pour le Python)

    Tu as fait de l’Ada ? Professionnellement ? C’est plutôt rare, comme expérience.

    Concernant le C, je maintiens que ce langage a – au minimum – un aspect formateur qui le rend quasi-indispensable. Comprendre les pointeurs est nécessaire si on veut être capable de programmer correctement, même en utilisant un langage qui « cache » les pointeurs (comme le Java ou le PHP).

  18. 26 février 2012    

    On est d’accord pour le C et même pour le JS, même si on peut simuler le privé avec le système de closures.

    Pour l’Ada, oui, j’en ai fait pour être exact. J’ai bossé 10 mois chez un fournisseur d’équipements électroniques « très grands comptes » (comprendre états et corps composites). Et là bas, j’ai dû faire de l’Ada. Ce langage y est très apprécié pour son hyper-restrictivité. Un programme écrit en Ada est tellement difficile à compiler qu’une fois que ça compile, tu sais que t’as de bonnes chances pour que ça fasse ce que c’est censé faire. Mais ça implique d’être bien plus violent avec soi-même niveau algorithmique. Même le casting de variables peut se transformer en calvaire.

  19. alienlar's Gravatar alienlar
    1 mai 2012    

    Salut Oelita; contrairement à toi; Clarion fut une délivrance pour moi.
    J’ai commencer à développer avec Pascal, Clipper et dbase; puis j’ai découvert Delphi, ce fut une suite logique à pascal, j’ai adoré. La révélation pour moi était Clarion en 2000 dans sa version 5.5. Il est est extraordinaire quant il s’agit de développer des applications clients serveur. Très vite on monte une appli avec des fonctionnalités de gestion de bases de données respectable, avec des instructions qui se comptent sur les doits de la main (celles qu’on utilise souvent) on peut faire des merveilles. l’exécutable généré peut être libre du système, il fonctionnera sur tous les Windows système 32bit. autant vous dire que pour la maintenance des applications, je n’ai pas trouver mieux (à ma connaissance). cela fait 12 ans que je travaille avec et rien à dire… j’ai touché en autodidacte à php/mysql; j’ai énormément apprécié. Enfin qu’un chacun trouve son bonheur avec quelque langage qui soit pourvu qu’il le maitrise à fond, il sera capable de faire des merveilles. Il est impossible de tous les connaître.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Notifiez-moi des commentaires à venir via email. Vous pouvez aussi vous abonner sans commenter.