Bonjour,
Je ne comprends pas le rapport.
Ou alors les LLMs vont directement fournir un binaire à partir d'un prompt?
C'est possible sans doute mais ça serait quand même assez dangereux il me semble :-)
Personnellement je préfère que les LLMs m'aident à faire l'inverse, décompiler un binaire (au hasard un dump de ROM) pour comprendre ce qu'il fait.
Non, je pense que les LLM fourniront un code qui sera compilé (ou pas suivant le langage), mais il y a déjà suffisamment de langages connu pour les LLM. L'avantage de Zig c'est juste d'être plus "cool", le LLM s'en fiche. Et combien d'humain apprendront à coder en langage informatique dans 30 ans ? Sans doute autant qui apprennent l'assembleur (et qui le maitrise à fond?).
En fait au départ, on programmait en assembleur, puis C est venu abstraire ceci. L'assembleur existe toujours, mais il n'est qu'une étape de compilation (Ou surtout de décompilation). Ensuite sont venu les langages qui compilent en byte-code qui plus ou moins tourne dans une VM… Le LLM rajoute une couche et le langage informatique n'est juste qu'un format de stockage du fichier programme sur lequel je travail.
Rust est à part, car il apporte un réel plus en terme de garanti de sécurité. Mais autrement je vois mal l'intérêt de faire émerger un nouveau langage, qui s'il émerge mettra 20 à s'imposer… Or si demain il y aura toujours des devs, dans 20 ils seront peau de chagrin (il y en aura, mais une fraction de ce qu'il y a aujourd'hui)
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Tu veux dire que étant donné que le corpus de code Zig disponible est relativement faible, les LLMs vont être particulièrement peu efficace pour quiconque voudrait vibe-coder en Zig, donc Zig n'a pas d'avenir ?
J'aurais plutôt conclus l'inverse finalement.
Mais c'est parce que je doute très fort que les LLMs soient l'avenir du codage.
De la même manière que les ordinateurs n'ont pas été l'avenir des mathématiques.
Une autre interprétation étant qu'étant donné que dans certain narratif l'IA va faire plus de trucs le langage et ses subtilités va devenir un détail qui n'intéressera plus grand monde ?
Du coup si ça devient un "détail" (considéré comme), ça devient difficile de faire émerger un langage parce que des gens qui seraient motivés pour suivre, faire grandir et utiliser en masse seront peu nombreux, ce qui tuerait un nouveau langage dans l'œuf ? C'est déjà le cas de plein de développeurs qui utilisent ce qu'on leur met dans les pattes pour bosser ou ce qu'ils connaissent déjà, ça risquerait d'amplifier ce phénomène ?
Le risque peut être aussi c'est que si l'IA devient relativement fiable pour éviter les bugs les plus classiques, les innovations qui permettraient de les éviter à la source deviennent moins intéressante. Ou que les syntaxes qui permettent d'être plus efficace et concis en évitant une grosse quantité de code deviennent moins intéressante si le code est de fait de plus en plus généré. Le langage naturel deviendrait une sorte de langage de programmation très haut niveau compilé par une IA.
Sinon je pense que le manque de code est pas trop un obstacle pour l'apprentissage automatique, étant donné que ça doit être possible de faire de l'apprentissage par renforcement sur la génération. Tu fais retenter le truc jusqu'à ce qu'il ait un programme qui fasse la même chose qu'un programme dans un autre langage maîtrisé sur la même tâche par exemple. Il y a un point de référence, la correction du programme sur au moins quelques tâche, c'est pas "complètement" ouvert comme "est-ce que tel truc est vrai" comme problème.
Et une partie de ce qu'a appris le modèle sur d'autres langages doit être aussi valable. Faut aussi voir ce qu'il est possible d'apprendre avec très peu d'exemples ("few-shot learning"), peut être que ça marche bien sur des nouvelles fonctionnalités d'un langage.
D'accord, mais pourquoi faire. Quand on a inventé l'ASCI, on ne s'est pas amusé a inventer un autre encodage. Enfin si les français on fait le leur, les donc on a unifié dans l'UTF-8 et puis basta. On ne s'est jamais dit, et si l'on encodait les majuscules avec les bits inverse des minuscules, ce serait plus facile à décoder, alors je cré mon encodage… On ne l'a pas fait car on ne décode plus à la main (Ou alors exceptionnellement). On a plutôt voulu unifier les standards. Et c'est clair que si demain on peut convertir tous les programmes AWK en un autre plus courant en automatique, on le fera. Garde tu des fichiers dans différents format sur ton PC? Non, car sinon, tu te dis, ah mince, cette chanson, je ne peux pas la lire avec ce lecteur. Pareil pour un programme. Tu n'a pas envie de maintenir plusieurs environnements (qui plus est avec des gestions différentes) pour faire tourner tes programmes.
La raison d'être de la prolifération des langages c'est qu'il y a toujours des humains pour se dire "ce serait sympa si", je trouve ce langage plus joli, j'aime pas l'indentation sous Python, je me sens plus à l'aise en Perl, l'Env node est trop puissant… ce sont plus des considérations humaines, pas de performances. Et même les considérations techniques diminuent, si une machine peut convertir les librairies.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Ah, le mauvais exemple…
ASCII ok, et puis ISO 8859-1 (ergo latin-1), cp-1250, et… latin-2, 3, 4, cyrillique, arabe, grec, hébreu, latin-5 (turc), latin-6 (nordique), Thaï, devanagari, latin-7 (balte), latin-8 (celtique), latin-9 (latin-1 mais en mieux), latin-10 (européen du sud-est).
Mais aussi l'US-ASCII, l'IBM-367, les codepage qui sont plus de 30…
Ouf, il en aura fallut du temps avant l'Unicode !
L'unicode, mais lequel ? UTF-8 ? UTF-16 ? UTF-32 ? Big ou Little Endian ? Et le GB 18030 alors ?
…
Et rien à voir entre l'encodage des caractères et les langages de programmation, en vrai.
L'encodage sert aux programmes, à « parler » de la même manière entrer eux.
Le langage ne sert pas aux programmes, mais aux programmeurs, et un même programme écrit en C, Rust, Go, Zig, D ou autre, peut passer les mêmes tests, ou preuves formelles, et fournir le même résultat.
Et tu n'as qu'un seul environnement à maintenir, puisque le binaire ne dépend pas - après compilation - du langage du code source.
C'est une interface humain-machine.
Ton commentaire est donc au bout du compte équivalent à « Mais pourquoi se faire ch… avec KDE, vu qu'il existe déjà Gnome ? ».
En fait au départ, on programmait en assembleur, puis C est venu abstraire ceci. L'assembleur existe toujours, mais il n'est qu'une étape de compilation (Ou surtout de décompilation). Ensuite sont venu les langages qui compilent en byte-code qui plus ou moins tournent dans une VM… Le LLM rajoute une couche et le langage informatique n'est juste qu'un format de stockage du fichier programme sur lequel je travail (Comme je stocke un fichier en odt avant de l'exporter en pdf).
Rust est à part, car il apporte un réel plus en terme de garanti de sécurité. Mais autrement je vois mal l'intérêt de faire émerger un nouveau langage, qui s'il émerge mettra 20 à s'imposer… Or si demain il y aura toujours des devs, dans 20 ils seront peau de chagrin (il y en aura, mais une fraction de ce qu'il y a aujourd'hui)
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
model: Okay, I can convert the C JSON parser to Zig. This will involve translating the enums, structs, global debug flag, and the parse_char and main functions to idiomatic Zig. Here's the Zig implementation:
[…]
Key Zig features used:
@import("std"): Imports the standard library.
const and var: Used for immutable and mutable variables, respectively.
Enums: C-style enums are translated to Zig enums, with .member_name for accessing enum values.
Structs: C structs are translated to Zig structs.
Pointers: *ParserContext for passing the context by reference.
@tagName(enum_value): A built-in function to get the string representation of an enum member, which is very convenient for debugging.
std.debug.print: Zig's equivalent of printf for debug output, with a more type-safe and flexible formatting syntax.
std.ascii.isWhitespace and std.ascii.isDigit: Used for character checks.
for (string) |c|: A concise way to iterate over characters in a string.
pub fn main() !void: The entry point for a Zig executable, indicating it's a public function that might return an error (though in this case, we're handling errors via STATE_ERROR).
Oups, Gemini vient juste de contre dire ta prédiction, il connaît déjà Zig et il a l'air de bien aimer en plus.
# Troll
Posté par abriotde (site web personnel, Mastodon) . Évalué à -10 (+1/-13).
Est-ce qu'un langage comme celui-ci à encore un avenir avec les LLM?
Honnêtement je doute qu'il puisse se faire une place au vue de la part de codage des LLM. Plus aucun langage ne pourra émerger.
Peut-être que je me trompe.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Troll
Posté par Nicolas Boulay (site web personnel) . Évalué à 4 (+1/-0).
Un langage dont le texte qui passe par un llm avant compile ressemblerait à quoi ?
"La première sécurité est la liberté"
[^] # Re: Troll
Posté par bistouille . Évalué à 2 (+0/-0).
Bonjour,
Je ne comprends pas le rapport.
Ou alors les LLMs vont directement fournir un binaire à partir d'un prompt?
C'est possible sans doute mais ça serait quand même assez dangereux il me semble :-)
Personnellement je préfère que les LLMs m'aident à faire l'inverse, décompiler un binaire (au hasard un dump de ROM) pour comprendre ce qu'il fait.
[^] # Re: Troll
Posté par abriotde (site web personnel, Mastodon) . Évalué à 0 (+0/-1).
Non, je pense que les LLM fourniront un code qui sera compilé (ou pas suivant le langage), mais il y a déjà suffisamment de langages connu pour les LLM. L'avantage de Zig c'est juste d'être plus "cool", le LLM s'en fiche. Et combien d'humain apprendront à coder en langage informatique dans 30 ans ? Sans doute autant qui apprennent l'assembleur (et qui le maitrise à fond?).
En fait au départ, on programmait en assembleur, puis C est venu abstraire ceci. L'assembleur existe toujours, mais il n'est qu'une étape de compilation (Ou surtout de décompilation). Ensuite sont venu les langages qui compilent en byte-code qui plus ou moins tourne dans une VM… Le LLM rajoute une couche et le langage informatique n'est juste qu'un format de stockage du fichier programme sur lequel je travail.
Rust est à part, car il apporte un réel plus en terme de garanti de sécurité. Mais autrement je vois mal l'intérêt de faire émerger un nouveau langage, qui s'il émerge mettra 20 à s'imposer… Or si demain il y aura toujours des devs, dans 20 ils seront peau de chagrin (il y en aura, mais une fraction de ce qu'il y a aujourd'hui)
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Troll
Posté par Yth (Mastodon) . Évalué à 6 (+4/-0).
Tu veux dire que étant donné que le corpus de code Zig disponible est relativement faible, les LLMs vont être particulièrement peu efficace pour quiconque voudrait vibe-coder en Zig, donc Zig n'a pas d'avenir ?
J'aurais plutôt conclus l'inverse finalement.
Mais c'est parce que je doute très fort que les LLMs soient l'avenir du codage.
De la même manière que les ordinateurs n'ont pas été l'avenir des mathématiques.
[^] # Re: Troll
Posté par thoasm . Évalué à 3 (+1/-1).
Une autre interprétation étant qu'étant donné que dans certain narratif l'IA va faire plus de trucs le langage et ses subtilités va devenir un détail qui n'intéressera plus grand monde ?
Du coup si ça devient un "détail" (considéré comme), ça devient difficile de faire émerger un langage parce que des gens qui seraient motivés pour suivre, faire grandir et utiliser en masse seront peu nombreux, ce qui tuerait un nouveau langage dans l'œuf ? C'est déjà le cas de plein de développeurs qui utilisent ce qu'on leur met dans les pattes pour bosser ou ce qu'ils connaissent déjà, ça risquerait d'amplifier ce phénomène ?
Le risque peut être aussi c'est que si l'IA devient relativement fiable pour éviter les bugs les plus classiques, les innovations qui permettraient de les éviter à la source deviennent moins intéressante. Ou que les syntaxes qui permettent d'être plus efficace et concis en évitant une grosse quantité de code deviennent moins intéressante si le code est de fait de plus en plus généré. Le langage naturel deviendrait une sorte de langage de programmation très haut niveau compilé par une IA.
[^] # Re: Troll
Posté par Yth (Mastodon) . Évalué à 4 (+2/-0).
Et la valeur ajoutée des gens qui comprennent ce qu'ils font, et avec un langage de qualité, devient d'autant plus grande ?
[^] # Re: Troll
Posté par thoasm . Évalué à 2 (+0/-1).
Sinon je pense que le manque de code est pas trop un obstacle pour l'apprentissage automatique, étant donné que ça doit être possible de faire de l'apprentissage par renforcement sur la génération. Tu fais retenter le truc jusqu'à ce qu'il ait un programme qui fasse la même chose qu'un programme dans un autre langage maîtrisé sur la même tâche par exemple. Il y a un point de référence, la correction du programme sur au moins quelques tâche, c'est pas "complètement" ouvert comme "est-ce que tel truc est vrai" comme problème.
Et une partie de ce qu'a appris le modèle sur d'autres langages doit être aussi valable. Faut aussi voir ce qu'il est possible d'apprendre avec très peu d'exemples ("few-shot learning"), peut être que ça marche bien sur des nouvelles fonctionnalités d'un langage.
[^] # Re: Troll
Posté par abriotde (site web personnel, Mastodon) . Évalué à 0 (+0/-1).
D'accord, mais pourquoi faire. Quand on a inventé l'ASCI, on ne s'est pas amusé a inventer un autre encodage. Enfin si les français on fait le leur, les donc on a unifié dans l'UTF-8 et puis basta. On ne s'est jamais dit, et si l'on encodait les majuscules avec les bits inverse des minuscules, ce serait plus facile à décoder, alors je cré mon encodage… On ne l'a pas fait car on ne décode plus à la main (Ou alors exceptionnellement). On a plutôt voulu unifier les standards. Et c'est clair que si demain on peut convertir tous les programmes AWK en un autre plus courant en automatique, on le fera. Garde tu des fichiers dans différents format sur ton PC? Non, car sinon, tu te dis, ah mince, cette chanson, je ne peux pas la lire avec ce lecteur. Pareil pour un programme. Tu n'a pas envie de maintenir plusieurs environnements (qui plus est avec des gestions différentes) pour faire tourner tes programmes.
La raison d'être de la prolifération des langages c'est qu'il y a toujours des humains pour se dire "ce serait sympa si", je trouve ce langage plus joli, j'aime pas l'indentation sous Python, je me sens plus à l'aise en Perl, l'Env node est trop puissant… ce sont plus des considérations humaines, pas de performances. Et même les considérations techniques diminuent, si une machine peut convertir les librairies.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Troll
Posté par Yth (Mastodon) . Évalué à 3 (+1/-0).
Ah, le mauvais exemple…
ASCII ok, et puis ISO 8859-1 (ergo latin-1), cp-1250, et… latin-2, 3, 4, cyrillique, arabe, grec, hébreu, latin-5 (turc), latin-6 (nordique), Thaï, devanagari, latin-7 (balte), latin-8 (celtique), latin-9 (latin-1 mais en mieux), latin-10 (européen du sud-est).
Mais aussi l'US-ASCII, l'IBM-367, les codepage qui sont plus de 30…
Ouf, il en aura fallut du temps avant l'Unicode !
L'unicode, mais lequel ? UTF-8 ? UTF-16 ? UTF-32 ? Big ou Little Endian ? Et le GB 18030 alors ?
…
Et rien à voir entre l'encodage des caractères et les langages de programmation, en vrai.
L'encodage sert aux programmes, à « parler » de la même manière entrer eux.
Le langage ne sert pas aux programmes, mais aux programmeurs, et un même programme écrit en C, Rust, Go, Zig, D ou autre, peut passer les mêmes tests, ou preuves formelles, et fournir le même résultat.
Et tu n'as qu'un seul environnement à maintenir, puisque le binaire ne dépend pas - après compilation - du langage du code source.
C'est une interface humain-machine.
Ton commentaire est donc au bout du compte équivalent à « Mais pourquoi se faire ch… avec KDE, vu qu'il existe déjà Gnome ? ».
[^] # Re: Troll
Posté par Pol' uX (site web personnel) . Évalué à 2 (+0/-0).
Et pendant ce temps, on utilise encore du Cork. :)
Adhérer à l'April, ça vous tente ?
[^] # Re: Troll
Posté par Lutin . Évalué à 2 (+0/-0).
Sûrement, mais probablement pas aux yeux des décideurs pressés malheureusement.
[^] # Re: Troll
Posté par abriotde (site web personnel, Mastodon) . Évalué à -1 (+0/-2).
Tout a fait.
En fait au départ, on programmait en assembleur, puis C est venu abstraire ceci. L'assembleur existe toujours, mais il n'est qu'une étape de compilation (Ou surtout de décompilation). Ensuite sont venu les langages qui compilent en byte-code qui plus ou moins tournent dans une VM… Le LLM rajoute une couche et le langage informatique n'est juste qu'un format de stockage du fichier programme sur lequel je travail (Comme je stocke un fichier en odt avant de l'exporter en pdf).
Rust est à part, car il apporte un réel plus en terme de garanti de sécurité. Mais autrement je vois mal l'intérêt de faire émerger un nouveau langage, qui s'il émerge mettra 20 à s'imposer… Or si demain il y aura toujours des devs, dans 20 ils seront peau de chagrin (il y en aura, mais une fraction de ce qu'il y a aujourd'hui)
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Troll
Posté par steph1978 . Évalué à 3 (+1/-0).
Bravo Mme Irma, sacré boule de crystal
Oups, Gemini vient juste de contre dire ta prédiction, il connaît déjà Zig et il a l'air de bien aimer en plus.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.