Discussion :

[Michael Guilloux]

Ritchie : un nouveau langage de programmation dérivé de C
Et qui veut combiner la facilité de Python et la vitesse de C

Depuis un peu plus d’un an, une équipe de développeurs travaille sur un langage de programmation baptisé Ritchie et qui repose sur le langage de programmation C. La vision de ces derniers est d’offrir un langage capable de combiner la concision de Python et l’efficacité du langage C, mais aussi d’autres caractéristiques propres aux langages de haut niveau.

« Ritchie est un langage expressif et efficace pour l’écosystème C », d’après sa description sur GitHub. Il « utilise des bibliothèques C nativement et génère un code C facile à comprendre ». Se rapprochant de sa première version, le langage a été conçu pour répondre à cinq principes de base :

• faciliter la programmation, en s’inspirant de Python ;
• offrir une rapidité similaire à celle de C ;
• offrir un langage de type sécurisé comme Scala ;
• offrir la possibilité d’écrire du code C ;
• Ritchie n’a pas de mots réservés, tout peut être redéfini.

Après avoir été comparé avec Python et C, selon le benchmark Prime Counting, Ritchie a été trouvé presque aussi rapide que C et plus concis que Pyhton. En effet, pour le code exécuté, son écriture en langage Ritchie a utilisé 423 caractères contre 542 pour C et 474 pour Pyhton. Et l’exécution du code s’est faite en 457 ms pour Ritchie, 424 ms pour C, et 7836 pour Pyhton.

Ritchie est encore en phase de développement et de nombreuses fonctionnalités n’ont pas encore été pleinement implémentées. Parmi les caractéristiques actuelles du langage, on peut toutefois noter :

• Ritchie est sensible aux espaces ;
• il utilise l’inférence de type. À titre d’illustration, si l'on considère l’identificateur point et le type Point, la déclaration Java passe-partout Point point = new Point (x, y) devient en langage Ritchie point = Point x, y ;
• le langage Ritchie utilise la notion de verbe pour regrouper ce que les autres langages appellent fonctions, méthodes ou sous-programmes ;
• Ritchie n'a pas de mots-clés. Il utilise par contre des symboles avec des significations prédéfinies, mais tous ces symboles pourraient être redéfinis. Ritchie a été développé avec une langue standard qui lui est propre. À cet effet de nombreux symboles qui fonctionnent comme des mots-clés pourraient avoir une autre utilisation dans d’autres langages. À titre d’illustration, pour définir une classe dans Ritchie, vous pourrez taper SomeClass :: SomeBaseClass. Le :: est tout simplement un verbe qui veut dire « devenir une sous-classe de » ;
• Ritchie essaie de suivre la construction linguistique (Sujet / Verbe / Objet) dans la plupart de ses expressions. Par exemple pour l’expression hello = "Hello", l’analyse donne hello comme sujet, = comme verbe et "Hello" comme objet ;
• le langage introduit un type spécial de verbes classés comme des verbes de contrôle de flux. If, Whileet Forfont partie de ce type de verbe, et ne sont donc pas des mots-clés comme dans les autres langages. Ils peuvent toutefois être redéfinis même si cela n’est pas recommandé.

La liste des caractéristiques de Ritchie et des fonctionnalités restant à implémenter est disponible sur GitHub.

Liste des principales tâches de développement restant avant d'atteindre la version 1.0

Source : GitHub

Et vous ?

Quels commentaires pouvez-vous faire des caractéristiques de Ritchie ? Quelles sont ses forces et faiblesses ?

[Gugelhupf]

Le langage Ritchie Rich par la compagnie Riz au Lait (c'était plus fort que moi désolé )
Il y a quelques exemples de code Ritchie ici. Je n'ai pas compris pourquoi ils mettent le test avant le mot-clé if ou while, histoire que le langage soit "différent" des autres ?
Je suis sûr que la création de ce langage part d'une bonne intention, un peu comme D pour C++, mais comme le dit Bjarne, sortir un nouveau langage aujourd'hui c'est pas gagné.

[Abacar94]

bonjour !
ce langage a l'aire prometteur; ce que je veut savoir; y a t'il des compilateur disponible pour ce langage ?

[ternel]

En pratique c'est un langage compilé vers le C. Avoir des performances équivalentes sur de petits programmes, ca me parait normal, pas vous?

L'idée clé du langage, à ce que je vois, c'est que toute instruction prenne la forme sujet verbe objet, par exemple a = 2 ou a<0 if a = 0.
Du coup, avoir utilisé if est un peu dommage, j'aurai plutot repris le ? : à cette place.

[robertledoux]

"Ritchie est sensible aux espaces ;"


mais pourquoi utiliser la pire chose de Python ?

[Aurelien Plazzotta]

Un langage dérivé de C pour opérer sur l'éco-système C . Belle performance...

Et + 1 pour Robertledoux !

[dalfab]

Bonjour,

Il est donc question de donner une seconde vie au C, en rendant hommage à Dennis Richie.

[steel-finger]

ça ma l'air un peux bizarre comme langage, sinon au niveau des perf c'est vrai que ça a l'air prometteur

[anykeyh]

Je n'ai pas compris pourquoi ils mettent le test avant le mot-clé if ou while, histoire que le langage soit "différent" des autres ?

Je crois comprendre que c'est du au fait qu'il n'y a aucun mot clé à proprement parlé. J'imagine que cette construction [variable] [mot cle structure] [nvelle ligne indentation] [block] devait permettre plus de liberté dans la redefinition des choses.

Effectivement, dans le cas du "if", ils auraient du l'appeler "then", car c'est plus lisible "x==0 then doSomething"

[maske]

Effectivement, dans le cas du "if", ils auraient du l'appeler "then", car c'est plus lisible "x==0 then doSomething"

En fait ça peut avoir une certaine logique, en smalltalk on a (condition) ifTrue:[bloc de code]. Là le mot n'est pas hyper joli mais tient la logique si on fait la gym dans sa tête.

En revanche, si on peut redéfinir ça alors rien n'empêche de changer le "if" en "then" ou "ifTrue" - mais j'aimerais bien voir des exemples de ça.

Est-ce qu'il y aurait plus de concrêt là dessus à part la page github, notamment pourquoi ils font ce langage et comment marche la redéfinition ? Ça a l'air de tenir un peu plus du DSL que d'un GPL, mais du coup il y a peut-être un champ d'application propre qui justifie le langage ?

[chrtophe]

l’exécution du code s’est faite en 457 ms pour Ritchie, 424 ms pour C, et 7836 pour Pyhton.

Il faut comparer ce qui est comparable, le C est compilé, le python c'est de l'"interprété d'ou le gros écart.

[Invité]

Salut forum,

Quels commentaires pouvez-vous faire des caractéristiques de Ritchie ? Quelles sont ses forces et faiblesses ?

• il utilise l’inférence de type. À titre d’illustration, si l'on considère l’identificateur point et le type Point, la déclaration Java passe-partout Point point = new Point (x, y) devient en langage Ritchie point = Point x, y ;

Je pense que c'est une mauvaise idée.
Cette idée est déjà utilisé en VB6/VBA (et bien avant même). Ce problème est déjà connu, pour le résoudre, on déclare Option Explicit ce qui permet de générer une erreur de compilation si cette variable n'existe pas déjà (Pas déjà déclaré quelque part dans le code peut importe la portée).

La plupart des développeurs diront qu'il faut toujours déclarer ces variables. Cela ne change rien que la programmation soit statique ou dynamique. C'est un problème indépendant.

Si une variable nommée point existe dans une portée accessible, la ligne point = Point x, y va redéfinir la valeur de la variable déjà existante appartenant à une portée différente si celle-ci existe déjà. C'est un comportement indésirable car on souhaite déclaré une nouvelle variable appelée point, puis lui affecter la valeur Point x, y, hors, une variable situé dans une portée différente existe déjà, et c'est cette variable qui va prendre la valeur Point x, y.

Au final, le code ne fera pas ce que l'on pense qu'il fait.

A moins qu'ils aient une méthode qui permettent de mettre les choses au clair dans le code, je pense que c'est une mauvaise idée.

Pour le reste du langage, je ne sais pas. A voir.
Mais si il génère du code C en sortie comme langage intermédiaire, c'est un grand avantage.
Si il permet d'utiliser les bibliothèque C en entrée, c'est un grand avantage également. Le must serait peut être d'avoir une bibliothèque standard interne (Ritchie Lib) et externe (C Lib).


P.S.:
En VB/C#, le mot clé Dim/var signifie "Je déclare une variable".


Pour l'Option Explicit:
http://www.developpez.net/forums/d12...t-on-s-passer/
http://bbil.developpez.com/tutoriel/...bles#LXIII-C-2
http://faq.vb.free.fr/index.php?question=190
https://msdn.microsoft.com/fr-fr/library/y9341s4f.aspx

[Tryph]

"Ritchie est sensible aux espaces ;"


mais pourquoi utiliser la pire chose de Python ?

il me semble que c'est justement l'une des meilleures choses de Python que de forcer une indentation correcte.
après j'arriverai à comprendre qu'un gars qui n'a pas l'habitude d'indenter correctement son code trouve ça chiant; mais dans ce cas le problème vient du gars, pas du langage.

[foetus]

mais dans ce cas le problème vient du gars, pas du langage.

Elle envoie du steak cella là

Je crée une contrainte débile et ensuite je m'en fiche: c'est au développeur/ utilisateur/ gars à se dépatouiller avec.


Analogie pourrie : Je suis constructeur automobile, pour des raisons X, je ne fais pas de portes. Parce que ce n'est pas si contraignant de passer par la fenêtre, c'est juste un petit détail

[Tryph]

indenter son code correctement n'est pas une contrainte débile, c'est juste une question de respect pour ceux qui vont devoir passer sur le code après soi (qu'on soit en Python ou dans n'importe quel autre langage).
par contre devoir se fader le code d'un professionnel qu'est pas foutu de faire une indentation correcte (et on sait tous qu'ils sont pas si rares que ça), ça c'est une contrainte.
indenter correctement son code c'est la base, ça doit être un automatisme pour n'importe quel gars un minimum sérieux, et pas que pour un dev Python.

sinon puisque le fait de devoir indenter son code te parait être une contrainte débile, que penses-tu de ces contraintes-ci?

1. ajouter un point-virgule en fin d'instruction (un saut de ligne ça devrait pouvoir suffire non?)
2. délimiter les blocs de code par des accolades (en quoi une accolade est moins débile qu'une indentation?)
3. ne pas pouvoir commencer un nom de variable par un chiffre (si je veux nommer ma variable 1664, je devrais pouvoir, non?)
4. etc, etc... (en fait un langage c'est juste un ensemble de règles plus ou moins arbitraire hein)

pour ton "analogie", je vois vraiment pas le rapport. mais puisque t'as l'air de bien aimer les voitures, je livre la mienne d'analogie:
"en France on n'est pas censé conduire bourré, c'est la base. Quand on passe le code on a même de grande chances de tomber sur une question traitant de ce sujet. bien entendu, il y a quand même des crétins qui s'imaginent que conduire bourré c'est pas bien grave et que rien ne devrait pouvoir nous empècher de le faire, d'autant que maintenant les voitures sont bardées d'assistances. pourtant des constructeurs commencent à intégrer des apareils pour vérifier le taux d'alcoolémie et empècher le focntionnement de la voiture en cas de non respect de la règle."

et au cas ou ça serait pas assez clair voici ce que ça pourrait donner appliqué au code (en quelque langage que ce soit):
"quand on code on n'est pas censé faire une indentation anarchique ou mettre toutes les instructions au même niveau, c'est la base. quand on poste son code sur un forum, on se fait rembarrer parfois violemment si le code n'est pas indenté et on passe pour un gignol si on montre du code non indenté en entretien. bien entendu y a des grands penseurs qui estiment que l'indentation c'est pour faire joli et que ça sert à rien, et que rien ne devrait nous obliger à faire une indentation propre; d'autant que si on veut du code indenté de nos jours suffit de demander à l'IDE de le faire pour nous. hè ben heureusement que certain langages permettent de remettre un peu ces guignols dans le droit chemin"


edit:
- si demain tu te retrouve à bosser sur du C avec un gars qui ne mets pas systématiquement les point-virgules à la fin des instructions, empèchant le programme de compiler, tu te diras que le problème vient du gars ou du langage?
- si la semaine prochaine, tu bosses en Java avec un gars qui ne déclare pas les variables avant de les utiliser, empêchant le programme de compiler, tu accuseras le gars ou le langage?
je pense que je connais les réponses que tu donneras à ces 2 questions (enfin j'espère). maissi un gars qui bosse en Python indente son code n'importe comment, empèchant ainsi le programme de fonctionner, là tu estimes que le problème vient du langage et pas du gars... pourquoi?

je pense vraiment que la "peur" de l'indentation imposée, c'est juste une question d'habitude de résistance à ce qu'on ne connait pas trop. et je pense ça parce que y a 3 ans, je me disais la même chose que les detracteurs de la syntaxe Python dont les arguments peuvent se résumer ainsi en général: "ça perturbe mes habitudes, alors j'aime pas".
bah au bout de bientôt 3 ans de pratique, à travailler uniquement sur du code bien indenté, je redoute vraiment le moment ou je vais devoir retourner sur un langage ou y aura toujours des comique pour mêler des espaces et des tabulations, pour ne pas corriger l'indentation quand ils modifient un bout de code en rajoutant (ou enlevant) un niveau de bloc.
et puis je me dis que ça doit être compliqué de faire respecter des conventions de codage à un gars qui estime que l'indentation est une contrainte débile... mais les conventions de codage ne sont peut être que d'autres contraintes débiles qui n'assurent en rien une homogénéité du code produit, et une facilité à le relire et le comprendre pour tous ceux qui respectent ces même conventions.

[gangsoleil]

Bonjour,

Je ne vois pas bien l'intérêt de ce langage : qu'apporte-t-il vraiment de plus par rapport à ceux existant ?

Et il a pour moi 2 inconvénients majeurs :

• son côté "Ritchie essaie de suivre la construction linguistique (Sujet / Verbe / Objet)" est mis en cause sur les structures conditionnelles : je ne connais pas de langue qui ne mette pas le SI en premier (français, anglais, espagnol, allemand, italien, ...), pareil pour le "tant que", ...
• il est sensible aux espaces : j'indente correctement mon code en C, et pourtant je n'ai jamais révé d'un langage qui en dépende

[foetus]

indenter son code correctement n'est pas une contrainte débile

Tu te trompes de contrainte : la contrainte ici c'est d'avoir un assistant qui te regarde d'un œil et qui te colle une mornifle à chaque fois que tu t'écartes des préceptes.

Et en C - C++, avoir une indentation libre permet justement des fois de compacter des lignes simples (2-3 affectations par exemple) afin de ne pas exploser la longueur de tes fonctions/ procédures/ méthodes/ fichiers.

[Bktero]

Et en C - C++, avoir une indentation libre permet justement des fois de compacter des lignes simples (2-3 affectations par exemple) afin de ne pas exploser la longueur de tes fonctions/ procédures/ méthodes/ fichiers.

Tu sauvegardes encore ton code sur des disquette d' 1Mo44 pour économiser ainsi 3 caractères ?

[Tryph]

Tu te trompes de contrainte : la contrainte ici c'est d'avoir un assistant qui te regarde d'un œil et qui te colle une mornifle à chaque fois que tu t'écartes des préceptes.

tu considère le fait qu'un compilo C gueule au moindre oubli de point-virgule comme une contrainte aussi? si oui, peux-tu m'expliquer en quoi cette contrainte est moins débile que celle que tu dénonces?

Et en C - C++, avoir une indentation libre permet justement des fois de compacter des lignes simples (2-3 affectations par exemple) afin de ne pas exploser la longueur de tes fonctions/ procédures/ méthodes/ fichiers.

on peut mettre plusieurs affectations sur une même ligne en Python avec une indentation "contrainte", je vois pas le rapport avec l'indentation

NB: pardon pour le HS à ceux qui sont interessés par la discussion de départ, mais j'aime bien comprendre les assertions qui me paraissent farfelues. mais je vous rassure: puisque la discussion semble être à sens unique, ça devrait pas durer longtemps

[abriotde]

Il faut comparer ce qui est comparable, le C est compilé, le python c'est de l'"interprété d'ou le gros écart

Il y a 2 problème pour la compilation d'un langage comme Python, pour l'optimiser
1) La gestion de la mémoire. Il faut savoir quel est le type de chaque élément pour savoir le lire et savoir quand libérer la mémoire. Pour faire tout ça dans un langage compilé il faut que le développeur précise des informations, ce qui complique la programmation. Sinon, on utilise un "ramasse miette" qui permet de gérer automatiquement la mémoire mais qui ralentit le programme.
2) La gestion du type des variables. Aujourd'hui grâce a l'inférence (Déduction du type) on arrive a le gérer assez efficacement.

Conclusion : Soit on fait un langage simple mais lent (Python, PHP, Javascript), soit on fait un langage rapide mais complexe (C) entre les deux on a tout un panel de langage plus ou moins typé, avec une gestion de mémoire plus ou moins automatique (Java, Go)

La force de se langage est de se rapprocher très près des performances de C avec une simplicité proche de Python (sans parler de la syntaxe un peu tordu inutilement a mon gout, cela va faire fuir les utilisateurs)