grim7reaper a écrit 132 commentaires

Python 8 arrive (le premier commit est déjà là).
LLVM rend enfin les Undefined Behavior agréable.
Linux vient à la rescousse de la communauté node.js (là aussi le code et la doc sont prêts).

Je suppose que c’est C#, auquel cas la traduction serait C-croisillon (C#), pas C-dièse (C♯).

Merci pour cette news.

Globalement d’accord avec ce que tu dis, mais pour ce point :

peuvent être écrites avec des espaces et des commentaires.

Ça se fait aussi en Python et Ruby.

Chrome fait aussi ce genre de chose, par exemple il précharge complétement le premier résultat de la barre d'adresse lors d'une recherche.

Oui, Chrome fait pas mal de truc du genre pour avoir l'air super rapide.

Seul défaut, peu de code d’exemple disponible pour apprendre les bonnes pratiques qui vont avec le langage, et de ce côté là, les codes de calcul scientifique sont souvent catastrophiques.

Heureusement, il y a des bons livres à ce sujet:

• Norman S. Clerman et Walter Spector. Modern Fortran: Style and Usage.
• Michael Metcalf, John Reid et Malcolm Cohen. Modern Fortran Explained.
• Arjen Markus. Modern Fortran in Practice.
• Damian Rouson, Jim Xia et Xiaofeng Xu. Writing Scientific Software: A Guide to Good Style.
• Oliveira Suely et David E. Stewart. Scientific Software Design: The Object-Oriented Way.

Il me semble que les avantages de ld se retrouvent surtout sur les gros programmes en C++.

Oui, exact. Ça doit être due au fait que les programmes C++ ont souvent beaucoup de symboles, et ces symboles sont longs et diffèrent de peu parfois (name mangling).
Du coup, comme il doit y avoir relativement peu de programmes en C++ dans base (je suppose que l’écrasante majorité c’est du C) le choix est moins surprenant.

(je signale au passage que l’auteur a écrit une série d’articles très instructifs sur les linker)

Pour ceux qui veulent lire la série sur les linkers, la liste des articles est ici (il y a même une recette Calibre pour en faire un e-book). Bonne lecture !

Gold est désactivé car étant écrit en C++, il est beaucoup plus lent à compiler que ld et n'apporte pas d'avantages significatifs en utilisation par rapport à ce dernier.

Autant pour la compilation plus longue, ça me surprend pas (C++ inside), autant le coup du « gold n’apporte rien par rapport à ld » me surprend. Étant donné que le but de GNU gold est d’être plus rapide et de consommer moins de mémoire (je signale au passage que l’auteur a écrit une série d’articles très instructifs sur les linker) que ld, j’entends plutôt le contraire (un exemple parmi d’autres) en général.

que les auteurs de PHP ne savent pas ce qu'ils font

Rien à redire sur tes autres liens, mais pour ces deux là c’est un peu limite : le problème n’est pas spécifique à PHP (Java aussi a été impacté, bien que le bug soit différent).

Le bug vient du fait qu’ils se sont basé sur d’une vieille implémentation (on peut les blâmer pour ça) de strtod par David Gay. Cela dit, beaucoup de monde se base là-dessus à ma connaissance, car il faut bien dire que c’est loin d’être trivial comme fonction…)
Tu noteras quand même que le bug était bien velu, même pour un développeur C chevronné. Et comme on sait que les développeurs de PHP c’est loin d’être des pointures en C…

Ça existe aussi en C++, depuis C++03 avec auto_ptr (mais qui était une catastrophe), et correctement depuis C++11 avec la sémantique de mouvement / unique_ptr.

Ça existe, oui et non…
La différence entre ça

#include <iostream>
#include <memory>

static void foo(std::unique_ptr<int> ptr)
{
    std::cout << *ptr << '\n';
}

int main()
{
    std::unique_ptr<int> ptr(new int(42));
    foo(std::move(ptr));
    // OUPS!!!
    foo(std::move(ptr));
}

et ça

fn foo(n: Box<i32>) {
    println!("{}", n);
}

fn main() {
    let n =  Box::new(42);
    foo(n);
    // OUPS!!!
    foo(n);
}

C’est ça

42
zsh: segmentation fault (core dumped)  ./oups

contre ça :

oups2.rs:8:10: 8:11 error: use of moved value: `n`
oups2.rs:8     take(n);
                    ^
oups2.rs:7:10: 7:11 note: `n` moved here because it has type `Box<i32>`, which is non-copyable
oups2.rs:7     take(n);
                    ^
error: aborting due to previous error

Dans un cas ça pète à la compilation (donc catastrophe évitée) dans l’autre ça pète à l’exécution (segmentation fault, youhou…).
Donc oui y’a des trucs qui ressemble à ça en C++ mais c’est pas équivalent.

En même temps, les allocateurs maisons ne sont pas utiles pour seulement les jeux AAA (un exemple parmi d’autres)

Quasiment tous les jeux modernes utilisent plusieurs allocateurs mémoire maison pour optimiser l'utilisation de la mémoire.

Rust ne permet pas ça pour le moment en effet (et c’est un gros manque de mon point de vue), mais c’est prévu

Et il n'y a aucun langage existant (à ma connaissance) qui permette de garantir la sureté de l'utilisation mémoire en présence d'allocation sur le tas (sans garbage collector, évidement). Par exemple, ni C++, ni Ada, ni D, ni Go ne le permettent (dans le cas de figure général évidement).

Ada apporte quand même pas mal de garantie à ce niveau-là (grâce aux vérifications d'accessibilités). Bon c’est peut-être pas aussi poussé que Rust (car pas basé sur le même mécanisme) mais ça élimine déjà une grosse majorité des problèmes.

J'ai un peu le troll facile, mais le développement/maintient de screen s'est arrêté il y a plus de 5 ans (veuillez excuser ma flemme de sourcer)

Pourtant il y a eu une release (4.2.1) il y a un an.
Mais c’est vrai que le développement a été au point mort pendant 6 ans (depuis 2008), mais Amadeusz Sławiński a repris le flambeau on dirait.

reynum:

En tout cas le projet me parait saint

vlamy:

Je trouve ça saint de ne pas embarquer une dépendance

Il y a eu une nouvelle réforme de l’orthographe ou je rate une private joke ?

Pour l'aliasing, il y a soit le keyword restrict du C qui est reconnu par pas mal de compilateur C++.

Oui, restrict existe en C et C++, mais comme tu le dis toi-même les compilateurs n’en font pas un usage optimal (sûrement parce que des gens l’utilise sans comprendre et que ça casserait leur code (ce qui ne serait pas un mal, soit dit en passant)).

Pour les CoArray, ça semble en effet loin d’être mature (pour ce que j’en lit sur comp.lang.fortran), ce qui est dommage car prometteur (sur le papier).

Il me semble que CUDA et OpenCL sont utilisable en Fortran aussi (aucune idée de ce que valent les outils, je n’y ai pas touché), cela dit c’est un problème moindre car tout les problèmes ne se prêtent pas au calcul sur GPU (mais ça reste un manque pour un langage dont le domaine principal est le HPC).

Sous iOS, je crois que c'est impossible.

Parce que l’environnement est très fermé. Sans cela, je pense que c’est possible.

Et puis, en un an de C++ je n'ai quasiment reporté aucun bug de compilateur chez Intel (sauf quelques optimisations qui n'étaient pas faites). Avec ifort, j'ai bien renvoyé une dizaine de bugs chez Intel en 3 ans. C'était des bugs qui concernaient le Fortran 2003, mais certains étaient vraiment génants.

Ouais, c’est un fait que les compilateurs Fortran soient plus bogués que les compilateurs C (et C++), et surtout sur les derniers standards (quand le support dudit standard est utilisable). Le fait qu’il y ai moins d’utilisateurs y est pour quelque chose.

Mais le Fortran a de vrais avantages par rapport au C++ pour ce qui est calcul numérique (pas d’aliasing, comme tu le dit, de vrai tableaux, la notion de parallélisation intégrée au langages, …).
Mais oui, les outils autour sont parfois limité (y’a bien quelques bibliothèques de tests unitaires, Doxygen pour la doc (pour les IDE, je n’utilise pas ce genre d’outil donc ça ne me manque pas), …).

pas de compilateur Fortran sur les téléphones par exemple

Et pourtant, c’est possible

Du coup, les langages fonctionnels pour le HPC, j'en entends souvent parler, mais je ne les vois jamais. Est-ce que c'est une réalité aujourd'hui où une direction que les universitaires (qui n'ont pas autant de contrainte historique que beaucoup d'industriels et qui ont dans leur rang beaucoup plus d'experts en langage fonctionnel) souhaitent prendre ?

Pour Haskell, il y a des bibliothèques comme Repa ou Accelerate.

Whaaa, un utilisateur de Usenet. Je pensais que, hors Warez, ça n'existait plus.

Et pourtant, Usenet est encore bien vivant et très actif sur certains groupes (comp.lang.ada et comp.lang.c par exemple)

Haut niveau (et bas niveau) c’est relatif.

Un développeur Web (ou même Java) va te rire au nez si tu lui dit que Fortran est un langage haut niveau.
Après, pas rapport à l’assembleur c’est plus haut niveau.
Et l’assembleur est plus haut niveau que le binaire ou l’hexa.

Tout est relatif.

Je n'ai jamais rien entendu d'une quelconque normalisation de l'assembleur

De part sa nature (avoir accès au jeux d’instructions du CPU sous-jacent), il est impossible d’avoir un unique langage assembleur (et donc quelque chose de normalisé).

je remarque qu'il existe plusieurs notations (AT&T ou Intel ?)

Ça n’est que de la syntaxe, la plupart des assembleurs (je parle ici du logiciel) supporte les deux syntaxes.

Je ne mets pas l'assembleur pur dans les langages de programmation.

Pourtant, c’en est un.

Dans le contexte des années 50 (je ne faisait pas d'informatique à ce moment là !) il n'existait que des programmeurs purs et durs.

Au contraire, je pense (peut-être à tord) qu’à l’époque la plupart des informaticiens était des scientifiques (matheux et physiciens surtout) plus ou moins reconvertis.
Il ne devait pas y avoir de cursus « informatique » dans les universités.

L'invention de Fortran visait à rendre accessible l'écriture de programmes aux personnes n'ayant rigoureusement aucune qualification en programmation. Et donc à se passer de programmeur.

Pour avoir bosser sur un modèle de simulation écrit par des non-développeurs prendant près de 10 ans, je peux te dire que « se passer de programmeurs » est une très mauvaise idée…
Le code s’est développé de manière organique et est impossible à maintenir ou faire évoluer. Aux dernière nouvelles, il était en cours de réecriture par un « vrai » informaticiens.

le but d'un langage de programmation est de générer un source assembleur.

Mauvaise définition (beaucoup de langages de programmation ne respecte pas cette définitions)

Oui, j‘ai fait un raccourci un peu rapide (qui pourrait laisser entendre que l’ABI du C est standardisé au même titre que le langage).

On est d’accord que l’ABI du C dépends du système mais c’est déjà beaucoup moins variable que celle du C++ (surtout à cause du name mangling (du coup, ça varie entre compilateurs)) et stable (on peut avoir des suprises entre versions du même compilateur, GCC 5 pète l’ABI du C++).

Donc, ce que je disais reste vrai : c’est casse-couille de s’interfacer avec du C++, mais avec du C c’est très simple.

Le langage Fortran (historiquement le plus ancien des langages de programmation)

Nope, le plus ancien langage c’est l’assembleur (1949).

a été inventé à une époque où les programmes tournaient sous hyperviseur et non pas sous système d'exploitation (pas encore inventé).

Nope, il est encore plus vieux que ça.
Le premier hyperviseur est sortie dans les années 60 il me semble.
La première version de FORTRAN en 1957.

Ceci a fait que Fortran, dès ses débuts, devait gérer lui-même les lectures-écritures des fichiers en mémoire vive et aussi les entrées-sorties sur les périphériques. Par exemple, Fortran a toujours connu le principe des fichiers temporaires en mode virtuel (fichiers scratch).

Hum, ça dépends ce que tu appelles « débuts »… À ses débuts, FORTRAN n’avait même pas la notion de fichiers.
Les scratch files dont tu parles sont apparus en FORTRAN 77 (d’ailleurs avant FORTRAN 77 il n’y avait même pas de type CHARACTER, on devait utiliser les constantes d’Hollerith).
Et un truc aussi basique que accéder aux arguments de la ligne de commandes (argv en C) était impossible de manière portable avant Fortran 2003 (GET_COMMAND_ARGUMENT), avant il fallait passer par des fonctions spécifiques au compilateur. La joie…
Encore, mieux pour lancer une commande externe (genre ls) il aura fallut attendre Fortran 2008 pour avoir un truc standard (EXECUTE_COMMAND_LINE).
Ça me fait doucement rire de lire que Fortran savait tout faire depuis ses débuts. On en est loin.

Par contre la gestion des fichiers est d'une toute autre ampleur !

Fortran ne va pas t’apporter de gain de performance sur la gestion des fichiers, les I/O c’est limité par le disque de toute façons, pas par le CPU (pour du traitement de données en mémoire ouais Fortran va sûrement être performant, mais pour des I/O sur des fichiers sur disques, non).

Est-il nécessaire de rappeler que Fortran est presque entièrement interopérable avec C/C++ (donc la libc !) de nos jours ?

Avec le C++ ça m’étonnerait, vu que l’ABI est pas standardisé.
Par contre avec le C ouais, surtout depuis Fortran 2003 :)

Attention, je ne remet pas en cause le choix du Fortran (qui est un langage que j’apprécie aussi, au cas où mon message laisserait penser le contraire) pour ton moteur de blog, je trouve ça même carrémment cool :)

OggAlbumTagger fonctionne selon un mode interactif que je pense plus pratique.

Si tu as quelques milliers de fichiers à retagger comme tu le dis, alors je doute qu’un mode interactif sois ce qu’il y ait de plus pratique…