[Index Software] Coin des développeurs :]

[Tugdual]

Un grand absent de ta liste de langages : Rust !

Je suis en train de m'y initier, c'est assez déroutant en venant du C++.

Beaucoup de contraintes sont présentes pour apporter de la sécurité, en particulier autour de la mémoire.

Ainsi, il n'y a pas de pointeurs, mais des slices qui incorporent les limites de la zone mémoire qu'on veut pointer, empêchant les débordements.

Également, les désallocations se gèrent automatiquement sans ramasse-miette, empêchant les fuites de mémoire.

[Bubu]

Un grand absent de ta liste de langages : Rust !

Je suis en train de m'y initier, c'est assez déroutant en venant du C++.

Beaucoup de contraintes sont présentes pour apporter de la sécurité, en particulier autour de la mémoire.

Ainsi, il n'y a pas de pointeurs, mais des slices qui incorporent les limites de la zone mémoire qu'on veut pointer, empêchant les débordements.

Également, les désallocations se gèrent automatiquement sans ramasse-miette, empêchant les fuites de mémoire.

Merci. Je ne connais pas ce langage. Est-il basé sur une machine virtuelle ? Comment fonctionne la libération de mémoire automatique s'il n'y a pas de ramasse-miettes ?
Eviter les effets de bords, Java le fait très bien déjà. Impossible d'écrire ou de lire hors de la zone mémoire allouée. Ça génère une exception fatale. (Plantage du programme et la fin de son exécution).

[EDIT]: même avec les langages qui utilisent un garbage collector, on peut avoir des fuites mémoires (memory leaks). Mais dans ce cas on se lave les mains, ce n'est pas ma faute, mais celle du ramasse-miettes ! Sauf que les ressources les plus gourmandes ne sont pas gérées par les ramasse-miettes. Il faut les libérer soi-même.

Par exemple l'objet Bitmap en Java et en OpenGL: Donc je ne parle pas de native code car il est complétement intégré aux API Java, une fois qu'on en a fait une texture envoyée au GPU, il faut explicitement dire ".recycle" pour que la VM la supprime de sa mémoire ...

[Tugdual]

Merci. Je ne connais pas ce langage. Est-il basé sur une machine virtuelle ? Comment fonctionne la libération de mémoire automatique s'il n'y a pas de ramasse-miettes ?

Pas de machine virtuelle, c'est un langage compilé, avec des performances proche du C/C++ (au point qu'il est question de pouvoir l'utiliser dans le noyau Linux).

Pour la mémoire, une notion de « propriété » est présente : tout ce qui est alloué sur le tas dépend d'un unique « propriétaire » à un instant donné, cette propriété se propageant d'instance en instance selon les affectations, et c'est le dernier propriétaire qui libère la mémoire quand il disparaît. Tout ça est géré à la compilation.

Pour qui veut creuser, la documentation (très pédagogique) en anglais est ici, et une traduction en français là.

[Bubu]

Merci. Je ne connais pas ce langage. Est-il basé sur une machine virtuelle ? Comment fonctionne la libération de mémoire automatique s'il n'y a pas de ramasse-miettes ?

Pas de machine virtuelle, c'est un langage compilé, avec des performances proche du C/C++ (au point qu'il est question de pouvoir l'utiliser dans le noyau Linux).

Pour la mémoire, une notion de « propriété » est présente : tout ce qui est alloué sur le tas dépend d'un unique « propriétaire » à un instant donné, cette propriété se propageant d'instance en instance selon les affectations, et c'est le dernier propriétaire qui libère la mémoire quand il disparaît. Tout ça est géré à la compilation.

Pour qui veut creuser, la documentation (très pédagogique) en anglais est ici, et une traduction en français là.

Merci je vais me renseigner grâce aux liens que tu as donnés.
Juste au passage, un langage utilisant une machine virtuelle est aussi compilé au préalable : Le java est compilé en bytecode avant d'être envoyé sur une machine virtuelle. Qui est un émulateur de processeur universel. La machine virtuelle par contre est spécifique à chaque OS.

[Tugdual]

Juste au passage, un langage utilisant une machine virtuelle est aussi compilé au préalable : Le java est compilé en bytecode avant d'être envoyé sur une machine virtuelle. Qui est un émulateur de processeur universel. Qui lui est spécifique à chaque OS.

C'est de la pseudo-compilation, puisque le bytecode n'est pas directement exécutable par le processeur.

Rust, comme C/C++, génère du code directement exécutable par le processeur.

[Bubu]

Juste au passage, un langage utilisant une machine virtuelle est aussi compilé au préalable : Le java est compilé en bytecode avant d'être envoyé sur une machine virtuelle. Qui est un émulateur de processeur universel. Qui lui est spécifique à chaque OS.

C'est de la pseudo-compilation, puisque le bytecode n'est pas directement exécutable par le processeur.

Rust, comme C/C++, génère du code directement exécutable par le processeur.

Tout à fait d'accord.
Le bytecode est, grâce à une machine virtuelle, exécutable quel que soit l'OS, sur lequel elle est installée. (Il y a forcément des pertes en performances vu que c'est un processeur émulé)
Le code natif, est forcément plus performant. Le problème, c'est qu'il faut faire les portages pour chaque OS existant.
C'est à juger au cas par cas.
Pour les jeux, où on n'aura jamais de performances suffisantes, c'est inadapté clairement. Il faut des langages bas niveau pour faire du haut niveau.
Mais pour les autres applications, on s'en fout. On en a déjà assez largement, des performances.

Réponse à Tugdual : On s'en moque que le bytecode ne soit pas directement exécutable par les processeurs. Pour le jeu pour Android en 2D (Bien qu'utilisant la 3D avec le z ignoré, et du normal mapping facile. Car il n'y a que l'orientation qui compte en 2D, juste l'angle. Pour l'écran titre et le magasin), j'ai franchement halluciné sur la puissance de calcul des mobiles.
J'ai hésité au début à installer le SDK NDK, qui permet d'utiliser du C++ sous Android. Même pas besoin ! Je peux afficher des milliers de sprites animés sans que ça rame ! En Java. (Et une petite API que j'ai faite pour utiliser OpenGL de manière invisible pour les afficher. Des sprite batches (On ajoute les images à afficher dedans). En gros en un draw call, j'affiche tout d'un coup).

[Bubu]

Je peux vous fournir le code source de mon petit moteur 2D pour Android si vous voulez. Projet AndroidStudio.
Il gère les différentes pages et les différents calques qui les composent.
Il gère les ressources également. (Une texture à la fois, les shaders, les bruitages, les musiques).
Il gère les différentes langues. On peut les changer sans redémarrer l'appli.
Pour les matheux, vous pouvez programmer vos propres shaders.
Le système d'achat en ligne par contre est obsolète.
Systèmes tactile et graphique simplifiés.
Les repères tactiles et graphiques sont les mêmes.
Bien qu'exprimées en pixels, les résolutions ne sont pas à prendre comme telles. L'API fournit les donnés pour que ce soit indépendant par rapport à la résolution de l'écran.

Il est en Java.

[Tugdual]

Pour les jeux, où on n'aura jamais de performances suffisantes, c'est inadapté clairement. Il faut des langages bas niveau pour faire du haut niveau.
Mais pour les autres applications, on s'en fout. On en a déjà assez largement, des performances.

Ça ne se passe pas comme ça, et il n'y a pas que les jeux qui ont besoin, ne serait-ce que ponctuellement, de puissance de calcul.

Dans toute application, on peut identifier des parties pour lesquelles la performance maximale est indispensable, et d'autres parties pour lesquelles l'impact des performances est négligeable. On peut alors décider de choisir le langage des différentes parties selon les besoins (par exemple via des bibliothèques optimisées).

Un point dont il est rarement question quand on compare les langages compilés / semi-compilés/ interprété, est la performance énergétique.

La phase de compilation est une phase consommatrice de ressources et donc consommatrice d'énergie.

En gros :

• langages compilés : la compilation n'a lieu qu'en phase de développement, jamais à l'utilisation ;
• langages semi-compilés : la compilation a lieu à chaque première utilisation ;
• langages interprété : la compilation a lieu à chaque utilisation.

D'un point de vue énergétique, il est donc clair qu'un logiciel destiné à être exécuté par des millions d'utilisateurs et à grande fréquence, consommera sur son cycle de vie beaucoup moins d'énergie qu'un script.

À l'autre extrémité, un script développé par un chercheur pour son travail sera si peu utilisé que le point de vue énergétique est négligeable.

Je serais curieux de voir des études sérieuses sur ces aspects, et je crois qu'il y aurait de quoi halluciner, rien qu'en voyant tous les langages utilisés sur les serveurs web...

[Bubu]

C'est vrai que j'ai trop simplifié les choses et que je n'ai pas pris en compte la consommation d'énergie.
Les gros GPUs sont energivores, un truc de malade.

Un langage interprété n'est pas compilé, il est, en temps réel, converti en langage machine in fine.
Et un langage basé sur une machine virtuelle est compilé tout comme les langages compilés vers le langage machine. La différence, c'est que c'est compilé pour un processeur virtuel, émulé. Mais je l'avoue volontiers, une machine virtuelle, mais si c'est ultra optimisé, a un coût en performances. Mais c'est presque négligeable sauf pour les applis qui font du calcul intensif et que la seule chose qui compte, ce sont les performances.

Mais les langages qui utilisent une VM, ont leurs avantages et leurs inconvénients, tout comme les langages compilés en langage machine.
Car il y a le cout de développement (temps, argent et donc énergie aussi) pour faire tous les portages (aidés en C++ par CMake d'accord) qui est minime (idéalement et souvent nul) pour les langages basés sur une VM.

Quand j'étais étudiant, j'avais Ubuntu et Windows sur ma machine. Pour les projets d'étude qui étaient en Java ou en SmallTalk (langage qui me répugne), je pouvais utiliser l'un ou l'autre OS. Pas de différence sur l'appli finale. Les interfaces étaient exactement identiques, et finalement, l'OS employé n'avait aucune incidence. Je passais de l'un à l'autre, et c'était pareil.

Je vous déconseille fortement de vous mettre au SmallTalk. C'est un langage de snob. Mais il faut reconnaître qu'ils ont inventé les machines virtuelles et les ramasse-miettes. Donc ça impose le respect.
Et en plus, un truc complétement inédit et qui n'a pas été suivi après, c'est que tout est objet, absolument tout. Le code est objet, les classes sont objets, les objets en terme de code évidemment.
Les nombres entiers peuvent aller jusqu'à l'infini aussi, il gère les points 2D directement aussi. Même le ramasse-miettes est objet.

L'ombre et la grosse c'est que ça nous ramène à du code qui a des performances catastrophiques. Et leurs interfaces graphiques sont misérables, on se croirait à l'époque de Windows 95.

Un délire de chercheurs, qui ont oublié la calculabilité, les performances d'un programme.

Mais il y a une communité très soudée aujourd'hui encore de développeurs SmallTalk. Je crois que le créateur de Wikipédia est un SmallTalker engagé et assumé.
(Car même si la syntaxe de ce langage est loufoque (rien à voir avec les syntaxes dérivées du C), il y a toujours des personnes qui persévèrent à l'utiliser). Ce n'est plus raisonnable, c'est de l'idéologie.
Une fois que l'on s'est fait à sa syntaxe bizarre, il y a beaucoup de points positifs. La gestion des données est exemplaire. Les collections. (tableau, liste, dictionnaire (qui correspond aux tables de hash) entre de multiples autres). Mais au bout du compte, se retrouver à faire un Tetris qui rame sur un ordi à 4 cœurs ...

Un autre truc sur SmallTalk beaucoup plus grave, il n'y a pas de droits sur les méthodes, appelées messages (car ils ont leurs propres termes ésotériques) . Elles sont toutes publiques. Donc si on veut éviter que les méthodes internes puissent être appelées de l'extérieur, il faut faire des blocs et non des méthodes. Bonjour la sécurité...
Donc pour résumer, les données et les blocs (qui sont des variables comme les autres, car je l'ai dit, le code est objet) sont privés, et les messages (méthodes) sont publics. Et le "protected" n'existe pas. (Pour l'héritage, c'est pourtant important).
Bref, le SmallTalk est un langage de merde, dangereux et qui offre des performances pitoyables, utilisé seulement par quelques chercheurs et des idéologues abrutis. Pourtant enseigné à la fac.

Bon je tire sur un animal mort, mais j'en rajoute. L' IDE de SmallTalk est lamentable, sans parler de leur interface graphique archaïque et absolument ni ergonomique, ni intuitive. C'est un ensemble de pop-ups.
Quand vous voulez entrer du code, on vous ouvre un bloc note primitif. Alors que les concurrents( beaucoup plus utilisés d'ailleurs) contrôlent le code en temps réel, proposant des suggestions, ou des infobulles pour compléter un nom verbeux explicite, voire même signalent des erreurs basiques (variable non initialisée lue, variable non accessible qui sert à rien du coup, doublons), ou d'étourderie, de codage pendant son écriture. Ils proposent également les membres (variables ou méthodes) des objets directement dans des petits menus contextuels). En SmallTalk, il faut exécuter le programme pour voir et corriger les erreurs et il faut tout taper, ce qui fait que l'on se retrouve avec des noms d'un caractère de variables donc dénués de sémantique.
Quand j'étais enfant, c'est comme cela que je corrigeais mes programmes en BASIC sur mon Apple 2c Il y a 30 ans. Mais c'était un langage interprété alors que le SmallTalk est un langage compilé...

Car dans un langage interprété, au delà des erreurs de syntaxe, on ne se rend compte des erreurs que pendant l'exécution.

Décidemment l'animal mort va finir en bouillie, en deuxième année j'avais fait un démineur en SmallTalk. 30 mégas au final (affligeant), car ils intègrent la VM dans l'exécutable. Je l'aurais fait en Java, il aurait au maximum fait quelques centaines de ko. (Pourtant ces deux langages reposent sur le même paradigme : ils sont compilés et exécutés par une machine virtuelle).

[Tugdual]

Quand mon énorme requête SQL :

• fonctionne du premier coup...

[lucius]

Pour ceux intéressés par le Machine Learning, voici des tutos web et vidéos du même créateur:

• Machine Learna

Et les vidéos sur youtube

[Tugdual]

Marion Créhange :

• pionnière française de l’informatique longtemps oubliée ;
• première personne à obtenir un doctorat en informatique en France ;
• Comment ai-je pu ignorer Marion Créhange ?

Modifications :

• 10/04/2022 : Ajout d'un lien.

[Tugdual]

10 idées de poisson d'avril :

• à faire à un développeur

Vu la perversité du truc, à réserver à la personne que vous détestez le plus :

10. Le pire de tous : le point d'interrogation grec

Le saviez-vous ? Le point d'interrogation grec est LITTÉRALEMENT un point-virgule, et il dispose de son propre code ASCII. Vous voyez où je veux en venir ?

Oui, c'est diabolique, je sais.

[Tugdual]

La Fondation Rust lance :

• un programme d'aide pour ses développeurs...

[Tugdual]

Lorraine Ipsum :

• le générateur de faux noms qu'il manquait à vos projets !
• Lien direct...