Le fil des geeks informatiques

[Rincevent]

  Le 05/11/2013 à 22:26, Theor a dit :

Autant que je sache, le seul succès du Pascal, c'est MacOS 7-9.

Mieux que MacOS 7 à 9, il y a Excel. Tu n'as jamais remarqué à quel point les opérations impliquant du texte étaient rapides sous Excel ? Je veux dire, à quel point elles ont toujours été rapides sous Excel. Même du temps d'Excel sous Dos. Parce qu'Excel considère les chaînes de caractère comme en Pascal.

Je m'en fous, du Pascal, en fait. C'est juste que Wirth avait plus de recul technique que Thompson et Richie, et donc que les chaînes de caractères sont mieux traitées en Pascal qu'en C.

  Le 05/11/2013 à 22:26, Theor a dit :

Et que le C est une sorte d'assembleur HLA qui rend l'archi des compilos assez directe, génère des binaires plus rapides, etc. 

http://benchmarksgame.alioth.debian.org/u64q/pascal.php

Et alors ? Pourquoi le commun des programmeurs devraient en avoir quoique ce soit à foutre ? Si on a inventé les langages de programmation, c'est précisément pour se passer des assembleurs. D'une part pour des raisons de portabilité (et là, le C fait en effet très bien l'affaire). Et d'autre part, parce que l'assembleur, c'est particulièrement pénible, et que lire de l'assembleur, c'est se garantir une mauvaise journée. A ton avis, pourquoi a-t-on développé des langages de programmation de relativement haut niveau plutôt que d'en rester aux assembleurs ou à une triste parodie ? Parce que le code, c'est fait pour être lu. Le programme est fait pour être exécuté, ça c'est certain ; mais le code source, lui, il sert avant toute autre considération à être lu.

 

  Le 05/11/2013 à 22:26, Theor a dit :

Et aussi parce que les langages verbeux, c'est moche.

Heu, lol. Si c'était le cas, le C aurait péri face à l'APL. Quant à moi, j'échange vingt barils de C contre un baril de Lisp, de Python ou même de Ruby.

[Theor]

  Le 05/11/2013 à 23:08, Rincevent a dit :

Je m'en fous, du Pascal, en fait. C'est juste que Wirth avait plus de recul technique que Thompson et Richie, et donc que les chaînes de caractères sont mieux traitées en Pascal qu'en C.

 

Et encore, la gestion des chaînes n'existe pas vraiment en C, tu travailles directement avec de l'array et un pointeur, et c'est vrai que ça a causé (et cause encore) d'énormes problèmes de sécurité. Enfin, ce n'est pas comme si je te l'apprenais.

 

  Citation

 

Et alors ? Pourquoi le commun des programmeurs devraient en avoir quoique ce soit à foutre ? Si on a inventé les langages de programmation, c'est précisément pour se passer des assembleurs. D'une part pour des raisons de portabilité (et là, le C fait en effet très bien l'affaire). Et d'autre part, parce que l'assembleur, c'est particulièrement pénible, et que lire de l'assembleur, c'est se garantir une mauvaise journée. A ton avis, pourquoi a-t-on développé des langages de programmation de relativement haut niveau plutôt que d'en rester aux assembleurs ou à une triste parodie ? Parce que le code, c'est fait pour être lu. Le programme est fait pour être exécuté, ça c'est certain ; mais le code source, lui, il sert avant toute autre considération à être lu.

 

Heu, lol. Si c'était le cas, le C aurait péri face à l'APL. Quant à moi, j'échange vingt barils de C contre un baril de Lisp, de Python ou même de Ruby.

 

J'ai bien reçu ton argument : Pascal a une place entre le compilé moyen-niveau et l’interprété haut niveau. Effectivement, je ne trouve rien à contre-argumenter à ça, d'autant que j'étais un fan de Delphi du temps du RAD (bouh, les odieux binaires monolithiques où tout était compilé en statiques avec des libs propriétaires type VCL)

 

Pour la verbosité, c'est une simple question de concision. Je préfères par exemple de loin travailler avec du JSON voir du YAML qu'avec du XML, c'est plus simple à parser, plus simple à mapper les variables, plus simple à lire. En général, un langage concis est également gage d'une RFC propre, de compilos propres, et de runtimes qui ne sont pas des OS embarqués. Quoique tu me diras, en abusant de templates et de libs boost, même le C++ peut devenir une bouillie odieuse. La STL, c'est pas fait pour les chiens.

 

+1 pour Ruby par contre, j'aime beaucoup le concept de scripts full object. Lua aussi est très sympa. Lisp, beurk.

Python, j'en mange tous les jours avec OpenStack et je suis un peu en overdose pour l'instant.

[h16]

  Le 05/11/2013 à 21:51, Rincevent a dit :

Qu'il marche, je te le concède avec bonne volonté. Mais si il marche, c'est en dépit du bon sens, de la logique, de la lisibilité et de la santé mentale de ceux qui en font.

 

Meuh non. Ce n'est pas parce que ça t'es hermétique que c'est n'importe quoi. Loin s'en faut.

[h16]

  Le 05/11/2013 à 23:08, Rincevent a dit :

l'assembleur, c'est particulièrement pénible, et que lire de l'assembleur, c'est se garantir une mauvaise journée.

 

Ménon.

 

Je serai assez pour qu'on interdise tous les autres langages à l'exception de l'assembleur d'une faible quantité de processeurs génériques (un ou deux CISC et un ou deux RISC). Ca calmerai largement la folie langagière, les langages de merde comme Java, les programmeurs à la petite semaine qui feraient mieux de faire de la broderie ou macramé. Et on retrouverait des interfaces texte pour les applis pro. Moins d'icones à la con, moins de clickodromes.

 

[h16]

  Le 05/11/2013 à 23:41, Theor a dit :

Et encore, la gestion des chaînes n'existe pas vraiment en C, tu travailles directement avec de l'array et un pointeur, et c'est vrai que ça a causé (et cause encore) d'énormes problèmes de sécurité. Enfin, ce n'est pas comme si je te l'apprenais.

 

 

J'ai bien reçu ton argument : Pascal a une place entre le compilé moyen-niveau et l’interprété haut niveau. Effectivement, je ne trouve rien à contre-argumenter à ça, d'autant que j'étais un fan de Delphi du temps du RAD (bouh, les odieux binaires monolithiques où tout était compilé en statiques avec des libs propriétaires type VCL)

 

Pour la verbosité, c'est une simple question de concision. Je préfères par exemple de loin travailler avec du JSON voir du YAML qu'avec du XML, c'est plus simple à parser, plus simple à mapper les variables, plus simple à lire. En général, un langage concis est également gage d'une RFC propre, de compilos propres, et de runtimes qui ne sont pas des OS embarqués. Quoique tu me diras, en abusant de templates et de libs boost, même le C++ peut devenir une bouillie odieuse. La STL, c'est pas fait pour les chiens.

 

+1 pour Ruby par contre, j'aime beaucoup le concept de scripts full object. Lua aussi est très sympa. Lisp, beurk.

Python, j'en mange tous les jours avec OpenStack et je suis un peu en overdose pour l'instant.

 

Le binaire monolithique, c'est horrible tant que l'espace est compté.

Et puis après, on se retrouve avec des lib partagées de tous les côtés, des distros différentes à n'en plus finir (linux, bonjour, windows bonjour², java bonjour³).

 

Pour LISP, le nombre faramineux d'applications grand public et industrielles qui existent montre à quel point ce langage est indispensable dans le monde actuel. Poubelle.

[Malky]

  Le 05/11/2013 à 21:45, Rincevent a dit :

Le succès du C et la domination mentale qu'il a exercé ont sans doute pourri l'informatique pendant vingt ans. Un langage-jouet, conçu pour un joujou aux possibilité délibérément limitées, collant de trop près aux particularités de la machine-mère (instruction ASCIZ, anyone ?), à la syntaxe délibérément confuse et inappropriée, qui donne au programmeur la sensation d'être près du métal, aussi bien pour lui faire peur quand il s'y attendra le moins que pour lui donner une confiance exagérée et dont il abusera... Mais pourquoi une telle horreur a-t-elle survécu ?

 

http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all〈=gcc&lang2=fpascal&data=u32

 

Need for speed, et Ada est venu trop tard – la domination du C était déjà bien en place.

[Mathieu_D]

  Le 06/11/2013 à 08:18, h16 a dit :

Ménon.

 

Je serai assez pour qu'on interdise tous les autres langages à l'exception de l'assembleur d'une faible quantité de processeurs génériques (un ou deux CISC et un ou deux RISC). Ca calmerai largement la folie langagière, les langages de merde comme Java, les programmeurs à la petite semaine qui feraient mieux de faire de la broderie ou macramé. Et on retrouverait des interfaces texte pour les applis pro. Moins d'icones à la con, moins de clickodromes.

 

 

Huhu dire que la mode ce sont les applicatifs avec des langages de flux tout en icônes.

 

Et c'est très bien, ça fait gagner un temps vertigineux.

[h16]

  Le 06/11/2013 à 08:45, Mathieu_D a dit :

Huhu dire que la mode ce sont les applicatifs avec des langages de flux tout en icônes.

 

Et c'est très bien, ça fait gagner un temps vertigineux.

 

Pour ceux qui les chient. Pour ceux qui les utilisent, ça en fait perdre un peu. Et pour ceux qui les maintiennent, c'est l'horreur.

[neuneu2k]

Le C est incomparable avec le lolPascal, je n'aime pas le C pour deux raisons:

• Une syntaxe un peu aberrante
• Trop riche

Des concepts de relativement haut niveau se baladent et se mélanges et sont contre-productifs pour un assembleur portable.

 

Pour ma part, je reste convaincu qu'il aurai fallu créer un C-- dédie clairement a la programmation système, avec un compilo capable d'inliner des segments de code en assembleur si nécéssaire (inliner à la compilation, pas linker !), moins typé (si si!).

 

Je n'aime pas lolPascal pour plein de raisons:

 

• La premiere c'est qu'il me prends pour un débile
• La deuxieme c'est que c'est un langage avec plein de défauts qui sont juste la pour permettre la compilation en une passe, je m'en fout que ça compile en une passe, on construit un langage pour ses utilisateurs, pas pour le compilo.
• La troisieme, c'est qu'il me prends pour un gros débile.

 

 

 

[neuneu2k]

  Le 06/11/2013 à 08:18, h16 a dit :

Ménon.

 

Je serai assez pour qu'on interdise tous les autres langages à l'exception de l'assembleur d'une faible quantité de processeurs génériques (un ou deux CISC et un ou deux RISC). Ca calmerai largement la folie langagière, les langages de merde comme Java, les programmeurs à la petite semaine qui feraient mieux de faire de la broderie ou macramé. Et on retrouverait des interfaces texte pour les applis pro. Moins d'icones à la con, moins de clickodromes.

 

 

Je ré-implémenterai immédiatement un langage fonctionnel de haut niveau et je ricanerai face à ta naïveté, les programmeurs à la petite semaine, ça fait aussi de l'assembleur, ce n'est pas le langage qui fait le débile, c'est le débile qui fait l'usage majoritaire du langage.

[h16]

  Le 06/11/2013 à 08:50, neuneu2k a dit :

un compilo capable d'inliner des segments de code en assembleur si nécéssaire (inliner à la compilation, pas linker !),

Heu. L'inline dans le C existe et fonctionne très bien.

[h16]

  Le 06/11/2013 à 08:52, neuneu2k a dit :

Je ré-implémenterai immédiatement un langage fonctionnel de haut niveau et je ricanerai face à ta naïveté, les programmeurs à la petite semaine, ça fait aussi de l'assembleur, ce n'est pas le langage qui fait le débile, c'est le débile qui fait l'usage majoritaire du langage.

 

Taratata.

La programmation devrait être réservée à une élite qui comprend comment fonctionne la bête en dessous. Ceux qui font de l'assembleur n'importe comment ne le font jamais très longtemps parce que ça finit par se voir très vite (je ne parle pas des bricoleurs qui font 1 ligne d'assembleur pour la galerie).

 

Et question naïveté, je souligne un truc vrai depuis la nuit des temps : il est bien plus aisé d'adapter les utilisateurs à un ordinateur que le contraire. Dès lors qu'on a essayé de le faire, on a obtenu les clickodromes plantogènes, les langages adaptés pour semi-débiles passifs et les OS playskools instables et jetables.

 

[Mathieu_D]

  Le 06/11/2013 à 08:47, h16 a dit :

Pour ceux qui les chient. Pour ceux qui les utilisent, ça en fait perdre un peu. Et pour ceux qui les maintiennent, c'est l'horreur.

 

Sur des trucs de niche très spécialisé j'ai fait les 3, et non, ça fait gagner du temps à tous les niveaux.

[neuneu2k]

  Le 06/11/2013 à 08:58, h16 a dit :

Taratata.

La programmation devrait être réservée à une élite qui comprend comment fonctionne la bête en dessous. 

 

Je suis d'accord, mais ce n'est pas une raison pour bosser en assembleur pour tous les étages du dev

 

Il faut savoir le faire, tout comme il faut savoir fraiser avant de faire de la CAO, mais ça ne signifie pas qu'on y passe nos journées non plus.

[Theor]

  Le 06/11/2013 à 08:50, neuneu2k a dit :

 

Le C est incomparable avec le lolPascal, je n'aime pas le C pour deux raisons:

• Une syntaxe un peu aberrante
• Trop riche

Des concepts de relativement haut niveau se baladent et se mélanges et sont contre-productifs pour un assembleur portable.

 

Pour ma part, je reste convaincu qu'il aurai fallu créer un C-- dédie clairement a la programmation système, avec un compilo capable d'inliner des segments de code en assembleur si nécéssaire (inliner à la compilation, pas linker !), moins typé (si si!).

 

Tu peux inliner de l'asm dans du C, du C++, du Pascal, et même du VB si tu veux. Le C-- existe déjà, c'est essentiellement un assembleur portable.

http://www.cs.tufts.edu/~nr/c--/

 

Ce que j'aime avec ce genre de langage, c'est la propreté du runtime. Ce que je n'aime pas, c'est le manque d'abstraction. Même en C, tu peux tout à fait déclarer quelques structures et faire du simili OOP. Avec un assembleur HLA comme le C--, il y a peu de marge de manoeuvre.

Enfin, si tu maîtrises l'archi de ta machine cible, tu peux écrire du C ultra-optimisé qui match la longueur des pipelines du CPU et optimise la prédiction de branchage. Par rapport à l'asm tu gagnes en mémoire mais presque rien en cycles CPU, et au prix d'un temps de dev et de débogage dix fois plus rapide. Référence à lire dans le domaine : Write Great Code: Understanding the Machine, Volume 1 et 2, Randall Hyde. J'avais adoré lire ça quand je finissais mes études.

[Calembredaine]

  Le 06/11/2013 à 08:18, h16 a dit :

Moins d'icones à la con, moins de clickodromes.

 

 

Le design c'est un métier à part entière. Un programmeur, aussi bon soit-il, s'il n'y connait fifre en design, pondra une merde non intuitive et inergonomique au possible. Un clickodrome.

 

C'est comme pour le Web. CSS c'est pour les designers ou les artistes, surtout pas pour les techniciens.

[Malky]

Tiens je viens de voir que le C passe assez mal au test du Steelman, c'est étonnant

 

http://www.dwheeler.com/steelman/steeltab.htm

[h16]

  Le 06/11/2013 à 09:06, neuneu2k a dit :

Je suis d'accord, mais ce n'est pas une raison pour bosser en assembleur pour tous les étages du dev

 

Il faut savoir le faire, tout comme il faut savoir fraiser avant de faire de la CAO, mais ça ne signifie pas qu'on y passe nos journées non plus.

 

Je ne suis pas complètement fermé à la déroute intellectuelle épisodique d'utiliser un langage haut niveau. J'insiste cependant sur "épisodique". Faut pas non plus déconner.

[h16]

  Le 06/11/2013 à 09:43, Rocou a dit :

Le design c'est un métier à part entière. Un programmeur, aussi bon soit-il, s'il n'y connait fifre en design, pondra une merde non intuitive et inergonomique au possible. Un clickodrome.

 

C'est comme pour le Web. CSS c'est pour les designers ou les artistes, surtout pas pour les techniciens.

 

Je suis d'accord. Mais dessiner une interface potable actuellement est finalement plus compliqué que jadis. Précisément parce qu'on peut se permettre bien plus de trucs. L'exemple des formulaires à la con avec 36.000 clics n'est pas fortuit. Dans un écran 80x25, c'est juste pas possible.

 

[Jesrad]

Donnez-moi Erlang et Lua, et c'est marre.

En passant, quitte à adapter les utilisateurs à la machine que l'inverse, commençons par apprendre le lojban

[neuneu2k]

  Le 06/11/2013 à 10:27, h16 a dit :

Je ne suis pas complètement fermé à la déroute intellectuelle épisodique d'utiliser un langage haut niveau. J'insiste cependant sur "épisodique". Faut pas non plus déconner.

 

Bah, 99% du code quoi, on garde l'assembleur pour faire le message passing à la limite et quelques structures de données optimisées.

 

Et encore, les CPU n'ayant quasiment plus de fonctions rigolotes de bas niveau ouvertes, à moins d'avoir le tournevis d'or qui ouvre le Xeon, on peut tout faire avec un langage de haut niveau.

 

Mais sur le fond, oui, sans savoir comment marche la machine au niveau intermédiaire (les bits, pas l'alliance maléfique entre la mécanique quantique et les radiofréquences du bas niveau), on fait de la merde quand on essaye de faire des trucs compliqués.

 

Par ailleurs, je suis un grand partisan de découper l'informatique en deux, le bottomware et l'applicatif, et l'applicatif, idéalement, c'est des users qui le font, ou des devs integrés dans les équipes utilisateurs, et eux, il leur faut un langage de haut niveau UNIQUEMENT, et vérifier qu'ils ne font QUE du business et pas du systeme.

 

Accessoirement, le retour du client/infra qu'est l'appli web moderne est une excellente occasion de faire ça (et il n'y a rien qui ressemble plus à un terminal 3270 modernisé que HTML5).

[jubal]

  Le 05/11/2013 à 23:08, Rincevent a dit :

Parce que le code, c'est fait pour être lu.

 

Non c'est fait pour être écrit !

C'est fait pour expliquer quelque chose a un ordinateur, et pour ça il vaut mieux un langage qui soit proche de lui et de son fonctionnement.

Si on est loin de l'ordinateur et de sa façon de penser on s'expose a des malentendus avec lui (des bugs, lui faire faire des trucs inutiles, etc.).

 

[Malky]

  Le 06/11/2013 à 14:53, jubal a dit :

Non c'est fait pour être écrit !

Ça dépend du code, mais la plupart du temps un code est lu plus souvent qu'il n'est écrit.

 

Sinon pour la différence haut/bas niveau, avant de bosser sur Ada, Jean Ichbiah était sur un projet (LIS) qui comportait deux langages (un bas niveau et un haut niveau) possédant des syntaxes relativement proches et de fortes capacités d'interaction. D'après lui le bas niveau c'était 5% du code au total (évaluation fin des années 70). C'est con qu'il ait arrêté ce projet, ça aurait pu donner qqch de bien.

[jubal]

  Le 06/11/2013 à 15:18, Malky a dit :

Ça dépend du code, mais la plupart du temps un code est lu plus souvent qu'il n'est écrit.

 

 

Ça n’empêche pas qu'il est pas fait pour être lu, ce n'est pas sa raison d’être.

C'est un problème que je vois souvent: des gens qui code pour faire du joli code, agréable a l’œil et a l'esprit, sans trop se soucier de ce que l'ordinateur va en faire.

 

[Malky]

  Le 06/11/2013 à 16:17, jubal a dit :

Ça n’empêche pas qu'il est pas fait pour être lu, ce n'est pas sa raison d’être.

C'est un problème que je vois souvent: des gens qui code pour faire du joli code, agréable a l’œil et a l'esprit, sans trop se soucier de ce que l'ordinateur va en faire.

 

Sais-tu combien de lignes de code sont embarquées dans une voiture moderne ? Il n'y a pas que les ordis dans la vie.

 

Quand un type bosse sur un algo d'ABS, il a intérêt à ne pas se chier. Et dans ce cas par exemple un code maintenable est fortement préférable à du Q&D, quelque soit la différence de performance.

[Greg42]

  Le 06/11/2013 à 16:17, jubal a dit :

C'est un problème que je vois souvent: des gens qui code pour faire du joli code, agréable a l’œil et a l'esprit, sans trop se soucier de ce que l'ordinateur va en faire.

En quoi c'est un problème ?

Du code lisible (parce que beau on s'en fiche un peu), c'est une maintenance plus facile, c'est une communication inter-équipe plus simple.

Franchement, dans l'ordre, les soucis dans le code sont plutôt :

- Le code mort

- Le code copié collé

- Le code illisible

- Le code pas testé

 

Normalement, l'optim c'est à la fin, si besoin, avec des outils de mesure.

[Jesrad]

D'où ma suggestion du Lojban, pour apprendre à causer machine directement, et donc aussi à lire, écrire et penser machine.

[Poil à gratter]

  Le 06/11/2013 à 17:48, Greg42 a dit :

En quoi c'est un problème ?

Du code lisible (parce que beau on s'en fiche un peu), c'est une maintenance plus facile, c'est une communication inter-équipe plus simple.

Franchement, dans l'ordre, les soucis dans le code sont plutôt :

- Le code mort

- Le code copié collé

- Le code illisible

- Le code pas testé

 

Normalement, l'optim c'est à la fin, si besoin, avec des outils de mesure.

Tout à fait: l'optimisation prématurée, rien de pire pour flinguer un projet.

 

Surtout qu'il y a malheureusement trop de développeurs qui n'ont aucune idée des ordres de grandeur qu'ils manipulent et qui vont passer du temps à optimiser des parties qui n'en ont aucun besoin. Genre rendre du code illisible pour optimiser une boucle de traitement, tout en laissant des appels de web service sans cache...

 

M'enfin bon, écrire du code bas niveau (ASM ou C) en 2013 faut vraiment en vouloir ou n'avoir rien de mieux à faire de son temps. Je me souviens d'une comparaison qui avait été faite entre la version originale de Git, écrite en C avec des  parties en assembleur, et un portage Java de Git (faudrait que je retrouve le post...). Conclusion: JGit était seulement 50% moins rapide que CGit lorsque la comparaison porte sur du calcul intensif. Soit sur une machine moderne, un truc qui doit se compter en micro-secondes pour une opération standard.

 

Ensuite devinez lequel est le plus maintenable et rapide à écrire...

[Malky]

  Le 06/11/2013 à 19:12, Poil à gratter a dit :

Ensuite devinez lequel est le plus maintenable et rapide à écrire...

 

Ça dépend, c'est avant ou après un changement majeur du langage Java ?

 

Sinon c'est aussi mon opinion (jusqu'à peu j'avais 'Premature optimisation is the root of all evil' dans ma signature )

[Theor]

Le micro-benchmark n'est pas pertinent pour mesurer la performance d'un système. Une routine critique genre memcopy qui met 50ms au lieu de 25, c'est au final un programme deux fois plus lent une fois en prod.

Avec l’essor de l'embarqué sous toutes ses formes et du green computing, même les frameworks JIT type JBoss/Tomcat ont maintenant tendance à laisser place au C/C++, tout du moins pour les backends. L'évolution Java/C est flagrante sur les dix dernières années quand on regarde l'indice TIOBE.

 

Quant au concept de haut et bas niveau, il n'est plus aussi pertinent qu'autrefois. C'est plus le paradigme que le langage qui détermine si ton code est haut niveau ou bas niveau. Tu peux écrire un pilote bas-niveau en Java si ça te dit (même s'il résidera en userland et que son comportement ne sera pas prédictible à cause du comportement non déterministe du ramasse miette), ou écrire du C très haut niveau façon Gnome/GTK... pas très élégant, mais très haut niveau quand même.