Tout d’abord, des exemples d’utilisation du langage pour la résolution de problèmes classiques comme celui de dénombrement du nombre d’occurrences d’un mot au sein d’une phrase ou encore le calcul des nombres d’une suite de Fibonacci.| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | Array {
countOccurrences(items Array<T>) {
map := Map.create<T, int>()
for items {
count := map.getOrDefault(it)
map.addOrUpdate(it, count + 1)
}
return map
}
}
main() {
::currentAllocator = Memory.newArenaAllocator(4096)
s := "How much wood could a wood chuck chuck if a wood chuck could chuck wood?"
freq := s.split(' ').countOccurrences() // Equivalent to: Array.countOccurrences(ref string.split(s, ' '))
for e in freq {
Stdout.writeLine(format("word: {}, count: {}", e.key, e.value))
}
} |
Dénombrement du nombre d’occurrences d’un mot au sein d’une phrase
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 | main() {
n := 7
a := 1_u
b := 1_u
for i := 1; i < n {
temp := a
a += b
b = temp
}
// alternatively, we could have counted down:
// for i := n; i > 1; i -= 1 { ... }
printf("%d\n", a)
} |
Calcul des éléments de la suite de Fibonacci
Les ressemblances sautent à l’œil pour un développeur habitué au langage C. En effet, on retrouve l’utilisation d’accolades ouvrantes et fermantes pour la délimitation des blocs de code ou encore l’utilisation de la fonction printf() pour l’écriture sur la sortie standard. Mais, le visuel met également ceux qui font un usage extensif du C d’accord sur le fait qu’il s’agit d’un autre langage de programmation ; il n’y a qu’a voir avec la forme de l’opérateur d’affectation (:=) ou l’usage prononcé de l’indentation. D’après ses auteurs, Muon est un langage inspiré de C, mais également de C# et du langage Go de Google. Deux de ses principes de conception résument ce qu’est Muon : langage de programmation impératif, à fort typage statique et orienté données. Le langage s’appuie de façon essentielle sur les fonctions, les structures, les énumérations et toutes les notions liées (pointeurs de fonctions, etc). Avec Muon, pas de notions de classes, d’héritage, etc.
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | // Guessing game
main() {
::currentAllocator = Memory.newArenaAllocator(16 * 1024)
rs := time(null) // Initialize random seed
num := cast(Random.xorshift32(ref rs) % 100 + 1, int)
while true {
Stdout.write("Your guess: ")
input := Stdin.tryReadLine()
if input.error != 0 {
break
}
pr := int.tryParse(input.value)
if !pr.hasValue {
continue
}
guess := pr.value
if guess < num {
Stdout.writeLine("Try higher")
} else if guess > num {
Stdout.writeLine("Try lower")
} else {
Stdout.writeLine("You got it!")
break
}
}
} |
Jeu de devinettes.
À la réalité, l’héritage du langage C, qui semble beaucoup plus perceptible que celui de C# et de Go fait débat sur certains aspects. Un commentaire sur la toile résume bien la situation surtout pour ce qui est des types de variables.
Envoyé par un internaute
J'ai une critique en ce qui concerne la façon dont les types de données de base sont nommés. Les noms de types comme long, short, char (et le très cher long long) ne devraient plus être utilisés dans un nouveau langage de programmation. Ils sont déroutants (de même que la réponse à la question : combien de bits y a-t-il dans votre int, long, short ? (dont on sait qu'elle dépend à la fois de l'architecture cible et du compilateur)) et depuis les années 70 nous avons découvert dans la douleur qu'ils ne sont pas extensibles. Il en va de même pour le sort du type char dans le monde post ASCII. Le langage C continue de conserver toutes ces antiquités pour les besoins de rétro compatibilité, mais l'usage de types comme uint32_t définis dans stdint.h est devenu une pratique courante pour les bases de code modernes.
Certains choix ne sont pas non plus compatibles avec C ou Go, ce qui ajoute à la confusion. En effet, sous Muon le type int a une taille de 32 bits et le type long a une taille de 64 bits sur toutes les architectures ! Donc, même pour les programmeurs C/C++ et Go, la nostalgie peut mener au piège. N'ayant aucune familiarité avec C# (je n'ai pas beaucoup fait usage de Windows depuis les années 90 et C# n'existe pratiquement pas pour Linux/macOS que Muon prétend cibler), j'ai creusé et il semble que ce choix est basé sur l'adoption déformée du standard C89 par le C#.
Go pour sa part définit le type int comme étant la taille du registre entier natif sur l'architecture cible (ce que j'aime bien parce que c'est ce que int est censé signifier à l'origine ; c'était la compréhension commune lors du portage de code du langage C vers l'assembleur), ce qui unifie uint et size_t, rendant size_t obsolète.
De façon ironique, Muon utilise le suffixe explicite du nombre de bits pour le type de données bool32 (alors qu'il n'y a pas de bool16 ou bool64). D'ailleurs, je ne sais même pas pourquoi on pourrait l'avoir comme type de base pour un langage de programmation.
J'espère vraiment que les créateurs de ce langage adopteront une convention de nommage similaire à celle de stdint.h dans C99 ou Go dont ils prétendent s'être inspirés
Certains choix ne sont pas non plus compatibles avec C ou Go, ce qui ajoute à la confusion. En effet, sous Muon le type int a une taille de 32 bits et le type long a une taille de 64 bits sur toutes les architectures ! Donc, même pour les programmeurs C/C++ et Go, la nostalgie peut mener au piège. N'ayant aucune familiarité avec C# (je n'ai pas beaucoup fait usage de Windows depuis les années 90 et C# n'existe pratiquement pas pour Linux/macOS que Muon prétend cibler), j'ai creusé et il semble que ce choix est basé sur l'adoption déformée du standard C89 par le C#.
Go pour sa part définit le type int comme étant la taille du registre entier natif sur l'architecture cible (ce que j'aime bien parce que c'est ce que int est censé signifier à l'origine ; c'était la compréhension commune lors du portage de code du langage C vers l'assembleur), ce qui unifie uint et size_t, rendant size_t obsolète.
De façon ironique, Muon utilise le suffixe explicite du nombre de bits pour le type de données bool32 (alors qu'il n'y a pas de bool16 ou bool64). D'ailleurs, je ne sais même pas pourquoi on pourrait l'avoir comme type de base pour un langage de programmation.
J'espère vraiment que les créateurs de ce langage adopteront une convention de nommage similaire à celle de stdint.h dans C99 ou Go dont ils prétendent s'être inspirés
D’après la note d’information des créateurs du langage, Muon vise un degré de performance égal à celui du langage C. Mais, l’équipe de développement n’a pas publié de comparatifs des performances du compilateur avec ceux disponibles pour le langage C. Le motif probable : la compilation de code Muon mène d’abord à l’obtention de code C par la suite transformé en exécutable par un compilateur C. L’équipe Muon annonce à ce propos qu’elle travaille à intégrer un backend LLVM pour permettre l’amélioration des performances. Autre grosse restriction pour le moment : l’actuel compilateur est conçu pour tourner sur une architecture 32 bits. L’équipe Muon a fait savoir qu’elle est à pied d’œuvre pour les plateformes Windows, Linux et macOS en 64 bits.
Source : GitHub
Et vous ?
Avez-vous déjà entendu parler de ce langage ? Êtes-vous d’accord avec la remarque sur le nommage des types de données ? Quels sont les aspects de la syntaxe qui vous plaisent ou déplaisent ? Muon peut-il au moins faire jeu égal avec le langage C comme recherché par ses auteurs ?Voir aussi :
Quel langage pourrait remplacer C ? Après avoir comparé Go, Rust et D, le choix d'Andrei Alexandrescu se porte sur D Pourquoi les langages C et C++ auraient-ils encore de nombreuses années devant eux ? Donnez votre avis C2 : un langage qui se présente comme une évolution de C, plus rapide, sans fichiers d'en-tête, avec système de build intégré et d'autres changements Le langage de programmation V sera disponible en open source à partir de juin 2019 et serait rapide, léger et capable de traduire vos projets C/C++ 
) qui ne sont ni mis à jour, ni supporté.