Moi aussi, ça m’inspire une question:
C’est quoi un « vrai » programme?
Dans mes multiples vies, j’ai développé, fait l’architecture ou géré des projets pour de l’embarqué (satellite, automobile, aéro, véhicule militaire, …), des clients lourds (applis de calculs scientifiques et simulations), des applis systèmes (systèmes sol satellite et contrôle aérien), du système d’exploitation (systèmes embarqués RT), des drivers, … Tout ça en Java, Ada, C, C++, Pascal, Fortran, Prolog, assembleur, scripts divers, QML, … Pour moi tous les projets portaient sur de vraies programmes, quelques soient le volume de code, les technos et la destination…
1 « J'aime »
Toujours est il que si on cherche la performance on devra se tourner vers autre chose. Au même titre que python.
Tout à fait.
Après, le problème c’est de savoir si on ferait pas mieux d’enseigner des langages plus rigoureux et plus performants d’emblée.
Le souci avec tout ces petits langages censés convenir à de petits usages, c’est que ça finit toujours par un certain nombre de gens qui tentent d’écrire de vrais programme avec. C’était déjà vrai avec le Basic il y a 35 ans et ça continue aujourd’hui avec d’autres langages.
Je voulais montrer que JavaScript évolue, on retrouve des annotations comme en java, des proxy, une nouvelle syntaxe.
Du coup tu jettes tout j’ai bien compris.
J’ai bien compris l’idée. Mais oui, clairement je jette tout pour une raison très simple. Comme vous le soulignez, on peut faire évoluer un langage sur certains points. Mais hélas, tout ne peut pas évoluer dans un langage de programmation. Certains éléments sont bloqués car ils sont liés à la définition même d’un langage.
Selon moi, il n’y aura donc pas d’alternative au fait de remplacer purement et simplement ce langage si l’on veut combler les besoins de vitesses de vraies applications autant que le fait d’économiser des cycles CPU et donc de l’énergie à tâche égale.
Il faut être réaliste, un langage qui ne te force pas à la rigueur (et qui n’est que peu rigoureux lui-même) va forcément engendré à un moment ou à un autre du code bordélique…
C’est exactement ça. Et hélas, cela ne manque pas d’arriver dans la pratique.
Vive Ada! Non, je déconne :-P. Quoique…
Je dirais qu’il y a un bon millieu à trouver entre des langages beaucoup trop laxistes et ceux qui sont trop rigoureux. Les deux aboutissent finalement à une perte de temps.
on, ça correspond assez bien à ce que je pense de JS. Mais tu y vas quand même un peu fort!
Yep, mais comme on dit, il faut appeler un chat un chat. Sinon le monde informatique va se traîner pleins de trucs pas terribles ad vitam aeternam.
1 « J'aime »
C’est quoi un « vrai » programme?
Par exemple, un système d’exploitation, un logiciel graphique de premier ordre, un moteur de jeu vidéo, une base de données.
Bref, tous ces logiciels de premier ordre qui sont la base de l’informatique. Il ne serait pas très heureux d’écrire ces trucs la en Javascript ou en Python.
Pour moi tous les projets portaient sur de vraies programmes, quelques soient le volume de code, les technos et la destination…
Certes, mais ce que je veux dire, c’est qu’il y a des problèmes que l’on ne rencontre pas tant que le projet n’atteint pas une certaine taille ou une certaine exigence de performance.
Le gros problème de tout ces « petits langages de script » utilisés « parce qu’ils suffisent », c’est qu’ils finissent rapidement et invariablement par être utilisés très au delà de leurs limites.
Et tous les informaticiens auront des sueurs froides à l’évocation du démon absolu, le cauchemar ultime, le boss de fin de niveau : La feuille de calcul Excell qui a grandi au point de devenir un ERP… 
2 « J'aime »
« Par exemple, un système d’exploitation, un logiciel graphique de premier ordre, un moteur de jeu vidéo, une base de données. »
Est ce qu’un « vrai programme » n’est tout simplement pas un programme qui doit répondre à un besoin. Peut importe le langage?
Oui, ce que tu cites sont de vrais programmes. Qui doivent être par la meme occasion performants.
Le logiciel de compta de l’entreprise au bout de la rue n’est pas un vrai programme?
« Le gros problème de tout ces « petits langages de script » utilisés « parce qu’ils suffisent », c’est qu’ils finissent rapidement et invariablement par être utilisés très au delà de leurs limites. »
Comme n’importe quel langage non? J’aime bien Rust, on pourrait peut être le qualifier de vrai langage selon toi (ou pas bref). Je reste pourtant bloqué quand je dois faire du GUI.
« Et tous les informaticiens auront des sueurs froides à l’évocation du démon absolu, le cauchemar ultime, le boss de fin de niveau : La feuille de calcul Excell qui a grandi au point de devenir un ERP… »
Tellement vrai 
1 « J'aime »
Est ce qu’un « vrai programme » n’est tout simplement pas un programme qui va répondre à un besoin. Peut importe le langage?
Oui, ce que tu cites sont de vraies programmes. Qui doivent être par la meme occasion performant.
Le logiciel de compta de l’entreprise au bout de la rue n’est pas un vrai programme?
Je comprends la controverse sur la notion de « vrai programme » et ce que cette notion peut comporter de flou. Mais ce n’est pas ce que j’ai voulu dire.
Il faut comprendre que ce n’est pas parce qu’il s’écrit tous les jours des milliers de programmes dans tous les langages qu’on peut en tirer pour autant des conclusions.
Tant qu’un programme reste petit et qu’il n’a pas besoin de beaucoup de performances, on peut le coder avec les pieds dans quasiment tous les langages. Et le monde de l’informatique ne s’en prive pas.
Par contre, quand il s’agit de projets d’envergure ou il faudra coder pendant des années (et s’y retrouver) et obtenir quelque chose de performant, le choix d’un bon langage devient crucial, faute de quoi le projet est condamné à terme.
Et donc, ce que je veux dire, c’est que ce sont ces projet la qui font vraiment ressortir les qualités et défauts des langages de programmation.
1 « J'aime »
Quand il s’agit d’un gros projet, un projet qui doit vivre des dizaines d’années; l’approche micro service me fait moins peur. Parce-qu’au final se dire qu’un langage est éternel est un sacré risque que l’on prend.
Ca me fait penser aux « énormes » projets en Cobol ou l’on se retrouve à faire du screen scraping, ou de la génération de code à partir de Java ou autre …
Comme n’importe quel langage non?
Certains langages ont des possibilités extrêmement larges. Demandez vous en quoi est codé un interpréteur Javascript. Et surtout, pourquoi il n’est pas lui même codé en Javascript.
J’aime bien Rust, on pourrait peut être le qualifier de vrai langage selon toi (ou pas bref).
Pour simplifier, je dirais que oui, Rust en tant que variante de C/C++ possède les caractéristiques d’un vrai langage car il est rigoureux et performant tout en évitant beaucoup de problèmes grâce à l’utilisation du bound checking et de bien d’autres contrôles pendant la compilation.
Après, si on veut rentrer dans les détails et qu’on le compare à C/C++, son concurrent désigné, il y a du pour et du contre. Je pense qu’a terme, ces deux langages seront moins concurrents qu’on ne le pense et qu’ils auront tous les deux leurs aficionados et leur domaine d’application privilégié.
Je reste pourtant bloqué quand je dois faire du GUI.
Rust est encore un peu jeune. Tu trouvera plus d’outils et de bibliothèques du côté de C/C++.
Quand il s’agit d’un gros projet, un projet qui doit vivre des dizaines d’années; l’approche micro service me fait moins peur. Parce-qu’au final se dire qu’un langage est éternel est un sacré risque que l’on prend.
Ca me fait penser aux « énormes » projets en Cobol ou l’on se retrouve à faire du screen scraping, ou de la génération de code à partir de Java ou autre …
Quand on programme quelque chose qui doit durer un certain temps, c’est effectivement un point crucial dont il faut tenir compte absolument.
Mais il faut savoir que tu as d’un côté les langages à la mode du moment qui vont durer quelques années tout au plus avant de disparaitre au profit de la mode suivante. Et de l’autre quelques trucs qui vont durer plus longtemps, voir beaucoup plus longtemps.
Par exemple, la langage C date des années 70… et il est toujours à la base des plus gros logiciels que nous utilisons.
On est tout à fait d’accord; Dart, Coffee Script, GWT et j’en passe.
Mais ce n’est pas si simple, je reprends Rust. Comme tu l’as dit plus haut il a tout l’air d’un langage prometteur mais aussi à la mode. Au fond qui me dit que d’ici 10 ans il sera toujours là?
Du coup la question se pose, je fais du C pour toujours? Ou j’essaies de me dire que peut importe. Le projet restera en « vie » tant qu’il y aura des développeurs. Quand il faudra migrer des parties quelque soit la raison on les migrera. C’est pour ca que je parlais d’une approche micro service, ou encore de conteneur.
On est tout à fait d’accord; Dart, Coffee Script, GWT et j’en passe.
Mais ce n’est pas si simple, je reprends Rust. Comme tu l’as dit plus haut il a tout l’air d’un langage prometteur mais aussi à la mode. Au fond qui me dit que d’ici 10 ans il sera toujours là?
Effectivement, rien ne permet d’en être sûr.
D’un côté, il est évident que Rust correspond à un besoin, ce qui plaide pour sa survie potentielle.
De l’autre rien ne dit qu’il ne sera pas supplanté par autre chose. Ou tout simplement parce que C/C++ pourrait finir par intégrer certaines des caractéristiques de Rust comme il l’a fait pour de nombreux autres langages au cours du temps.
Du coup la question se pose, je fais du C pour toujours?
IMHO, cela dépends du projet.
Si la durée de vie à long terme est un aspect recherché, c’est possible.
Néanmoins, si un projet avait un grand intérêt dans les caractéristiques particulières de Rust, il est évident que ce serait un point à considérer.
Ou j’essaies de me dire que peut importe. Le projet restera en « vie » tant qu’il y aura des développeurs. Quand il faudra migrer des parties quelque soit la raison on les migrera. C’est pour ca que je parlais d’une approche micro service, ou encore de conteneur.
En même temps, s’il faut re-coder, cela signifie remettre de l’argent pour le même logiciel. C’est bien pour ça qu’il existe encore des trucs en Cobol.
Après, il faut garder à l’esprit que Rust est un logiciel libre. Le code source est disponible. Donc, même en cas d’abandon du projet, cela ne signifiera pas pour autant sa disparition immédiate et brutale comme cela peut arriver avec des logiciels propriétaires.
Hello,
Python, langage côté serveur, reste un incontournable pour faire de l’IA vu qu’il propose beaucoup de bibliothèques pour générer des modèles. Ce langage faiblement typé est très voir trop permissif à mon goût. Pour la POO, il faudra être rigoureux (pylint?) et bien architecturer le code (UML?).
JavaScript, langage côté client est utile pour le développement de front-end responsive et dynamique mais attention à la sécurité.
Pour le back-end, je préfère C# pour sa robustesse et sa puissance des super classes abstraites. Ce langage fortement typé laisse peu de possibilités aux développeurs qui ne code pas proprement.
Pour le front-end, je préfère amplement le ReactJs qui gère nativement le DOM via AJAX.
Enfin, il est très difficile voire impossible de compiler un programme complexe en Python alors qu’en C# on génère des exécutables pour tout types de plateformes.
@++
C’est faux on peut faire sans (HTML5 + CSS3 apportent beaucoup de solutions), mais parfois c’est galère.
Javascript avec Vue.js et le framework Nuxt 
On peut faire avec les applis du bureau, mobile Android et iOS, et le site web responsive, c’est un tout en un avec juste un langage.
Il n’en reste pas moins une aberration de la nature !
1 « J'aime »
Très intéressant le tandem Vue.js / NuxtJS, Merci
Beaucoup de programmeurs s’investissent dans un seul langage. Ils en connaissent d’autres mais sont moins à l’aise. Là où il faut souvent deux langages, comme en mode Web, ils vont privilégier celui qu’ils connaissent le mieux, sans penser à l’homogénéité du système.
Depuis nodeJS, JavaScript est accessible sur serveur comme sur navigateur, on peut donc partager son code sur les 2 plateformes et se contenter d’un seul langage.
Il s’agit d’un langage intéressant, car objet, qui plus est lié au système des prototypes, assez bluffant, quand on connait.
On peut créer des applications desktops avec exactement les mêmes outils, ce qui nous fait trois environnements. Le seul souci, c’est la performance, donc pas de jeux exigeants, pas de nouveau système d’exploitation, mais il s’agit là d’une frange spécifique d’outils qui concernent une minorité de développeurs.
Qu’un programmeur C s’offusque de cela, je comprends, il est dans son univers. Il existe une multitude d’univers en termes de développement.
Il s’agit d’un langage intéressant, car objet, qui plus est lié au système des prototypes, assez bluffant
Oui, bluffant pour les bugs sous marins laissés par des pseudos génis…
Vanter le polomorphisme comme façon de programmer, c’est juste se reposer sur rien, le bordel entretenu, que souvent les auteurs eux-mêmes son incapables de débugger quelques semaines après… parce qu’ils ont trouvé une autre façon farfelue, cachée de faire.
Après, je suis d’accord pour dire que javascript est un langage pas optimisé, mais bon, quand on voit ce que font la plupart des programmes, faut pas non plus trop en faire…
Sinon, on en serait encore à programmer en assembleur, avec les pointeurs ‹ fous ›, l’octet de mémoire qui manque, etc…
Il y a un moment, il faut accepter les capacités des machines. J’en parle souvent, j’ai du mal à voir ce que l’on fait de plus depuis 25 ans… A part pragrammer comme des porcs, quand on compare la puissance d’aujourd’hui et qu’on fait quasi la même chose…
Je suis tombé sur tauri pour faire du desktop avec VueJS.
Vraiment beaucoup plus light que du électron. Avec la possibilité du rajoute du go, rust …
Ça
Python est devenu populaire à cause d’un des concepts les plus puissants existant: la simplicité. en pratique les gens n’ont pas besoin d’un langage plus rapide que tout, ils ont juste besoin de résoudre un problème ou répondre à un besoin rapidement. sa nature de langage « desktop » lui permet de jouer le rôle d’outil à tout faire. à voir si un autre langage plus efficient n’ira pas lui ravir sa place dans le futur.
Quant à javascript, c’est un simple langage d’habillage visuel, de conception graphique entièrement optionnelle. il peut aider un utilisateur à utiliser un site web mal conçu. il est intéressant de noter que ce petit langage est en train de servir temporairement à amorcer le virage des flux web asynchrone, des websockets. quand les principaux langages comme php auront entièrement assimilé ce concept, javascript retournera à son état d’habilleur optionnel de page web. il ne restera plus qu’à prier que google choisisse un autre langage que js et son moteur V8, et enfin nous serons débarrassés de ce langage simplet qui n’est sommes toute pas si infâme que ça, juste un peu gênant!