Je ne suis pas un guru de la programmation, mais je pense pouvoir te fournir quelques remarques qui te permettrons d'améliorer ton langage.
Pour l'ensemble de mes remarques, je vais suivre et commenter le ninja language reference http://ooc-lang.org/doc/langref/book1.htm (tu devrais rajouter dans la FAQ pourquoi c'est une référence Ninja).
http://ooc-lang.org/doc/langref/c31.htm
« All types should be in CamelCase, all variables and functions in camelCase. [...] The justification for that is consistency. »
Je ne vois pas en quoi le nomage des « types » en Java est incohérent. Les POD ont une minuscule parce qu'ils ne sont pas des objets. Si ton système est cohérent, alors on peut dériver depuis un Int. Dans le cas contraîre, c'est OOC qui est incohérent et non Java. À noter qu'ici Java est cohérent, raison de l'existence des classes Integer, Float, etc.
Quand au C++, la tradition est de ne jamais utiliser de majuscules. Que ce soit pour les noms de classe ou des fonctions. Seules exeptions, les noms de constantes ou les nom des paramètres de templates. Par exemple : void std::map<template T>::push(T &) ;
« You can declare several variables on the same line »
Mauvaise habitude. En plus tu montre que tu ne sais pas que le type pointeur n'existe pas en C/C++ (c'est un qualificatif).
« Correspondance with C and Java types »
En Java, je crois bien qu'on peu utiliser le mot-clé « self » dans la liste des paramètres et le type de retour des fonctions membre. En C++, je déclare souvent typedef Myclass self.
Je ne comprends pas cette prolifération de types numérique. Pourquoi ne pas proposer un type générique qui gère les opérations sur les nombres avec une précision arbitraire ? Ça permettrait de totalement abstraire l'usage des nombres, ce qui manque avec C++ et Java (il faut toujours faire attention aux limites, ce qui est rarement testé correctement, voir ignoré le plus souvent).
Le nom Octet est franchement maladroit, quant on sait qu'un byte ne fait pas forcément un octet. D'ailleurs, quelle est la taille de tes int (parce qu'en C, c'est dépendant de l'architecture, tout comme char) ?
« printf("A moins que vous n'epousiez la %s?\n", name); »
Pourquoi pas :
console.print "A moins que vous n'epousiez la %s?\n".format name ;
Je n'arrive pas à entrevoir l'intérêt des Covers sur la dérivation de la classe.
http://ooc-lang.org/doc/langref/x209.htm
Une critique qu'on peut faire au C++, c'est d'avoir conserver les tableaux à la mode C. Pourquoi faire la même erreur ? L'encapsulation des tableaux permet d'éviter la duplication des tests de contrôle, et surtout t'éviter tout problème de sécurité relatif au débordement de tampon (et de centraliser la correction d'un éventuel bogue). Ton langage impose déjà plusieurs paradigme : tu devrais aller au bout de ton idée. Sinon, autant faire du C ou du C++.
« A function is declared with the func keyword. »
Pourquoi un mot-clé ?
« func add(Int arg1, Int arg2) -> Int { } »
Argh... Je n'ai jamais compris cette logique que de noyer le type de retour après la list de paramètres (Pascal, Basic, etc).
« The main function: entry point »
Mais pourquoi une fonction ? :D
« SDL_Quit(); // We must use parenthesis, cause it's a C function »
On pourrait te reprocher une certaine incohérence à ce niveau là. Mais je comprends la limitation technique.
« Instanciation »
Je ne comprends pas l'intérêt du mot-clé new. En plus, de ce que j'en comprends, tes types ne sont jamais créé sur la pile ? Dans ce cas, tu devrais reprendre ton benchmark sur l'instantiation, et faire la création sur la pile. Tu verras que la différence de performances est... non-négligeable (l'instantiation sur la pile est ×ばつ plus rapide que dans le tas, chez moi).
Un objet peut-il être utilisé comme un functor ?
Les objets sont polymorphiques ?
Quelle est la portée par défaut des membres d'une classe ? Public ? N'est-ce pas là une violation du principe d'encapsulation ?
« for in ranges »
C'est pratique, indubitablement. Une bonne idée serait de rajouter un type Range. Pour éviter de déclarer des ensemble en dur dans les boucles. En embarquant le pas dans le Range, évidemment.
Tu aurais pu virer switch ;)
Pas de do..while ?
« The package of a source unit is relative to the sourcepath. »
Je ne penses pas que ce soit une bonne idée. Pour tout un tas de raisons, allant de la relativité du chemin au caractère dur du chemin. Bien que le mot-clé super permette de contourner partiellement ce défaut.
Voilà pour mes quelques remarques. J'espère que ça t'aidera dans ta réflexion.
# Critique du langage.
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 2.
Pour l'ensemble de mes remarques, je vais suivre et commenter le ninja language reference http://ooc-lang.org/doc/langref/book1.htm (tu devrais rajouter dans la FAQ pourquoi c'est une référence Ninja).
http://ooc-lang.org/doc/langref/c31.htm
« All types should be in CamelCase, all variables and functions in camelCase. [...] The justification for that is consistency. »
Je ne vois pas en quoi le nomage des « types » en Java est incohérent. Les POD ont une minuscule parce qu'ils ne sont pas des objets. Si ton système est cohérent, alors on peut dériver depuis un Int. Dans le cas contraîre, c'est OOC qui est incohérent et non Java. À noter qu'ici Java est cohérent, raison de l'existence des classes Integer, Float, etc.
Quand au C++, la tradition est de ne jamais utiliser de majuscules. Que ce soit pour les noms de classe ou des fonctions. Seules exeptions, les noms de constantes ou les nom des paramètres de templates. Par exemple : void std::map<template T>::push(T &) ;
« You can declare several variables on the same line »
Mauvaise habitude. En plus tu montre que tu ne sais pas que le type pointeur n'existe pas en C/C++ (c'est un qualificatif).
« Correspondance with C and Java types »
En Java, je crois bien qu'on peu utiliser le mot-clé « self » dans la liste des paramètres et le type de retour des fonctions membre. En C++, je déclare souvent typedef Myclass self.
Je ne comprends pas cette prolifération de types numérique. Pourquoi ne pas proposer un type générique qui gère les opérations sur les nombres avec une précision arbitraire ? Ça permettrait de totalement abstraire l'usage des nombres, ce qui manque avec C++ et Java (il faut toujours faire attention aux limites, ce qui est rarement testé correctement, voir ignoré le plus souvent).
Le nom Octet est franchement maladroit, quant on sait qu'un byte ne fait pas forcément un octet. D'ailleurs, quelle est la taille de tes int (parce qu'en C, c'est dépendant de l'architecture, tout comme char) ?
« printf("A moins que vous n'epousiez la %s?\n", name); »
Pourquoi pas :
console.print "A moins que vous n'epousiez la %s?\n".format name ;
Je n'arrive pas à entrevoir l'intérêt des Covers sur la dérivation de la classe.
http://ooc-lang.org/doc/langref/x209.htm
Une critique qu'on peut faire au C++, c'est d'avoir conserver les tableaux à la mode C. Pourquoi faire la même erreur ? L'encapsulation des tableaux permet d'éviter la duplication des tests de contrôle, et surtout t'éviter tout problème de sécurité relatif au débordement de tampon (et de centraliser la correction d'un éventuel bogue). Ton langage impose déjà plusieurs paradigme : tu devrais aller au bout de ton idée. Sinon, autant faire du C ou du C++.
« A function is declared with the func keyword. »
Pourquoi un mot-clé ?
« func add(Int arg1, Int arg2) -> Int { } »
Argh... Je n'ai jamais compris cette logique que de noyer le type de retour après la list de paramètres (Pascal, Basic, etc).
« The main function: entry point »
Mais pourquoi une fonction ? :D
« SDL_Quit(); // We must use parenthesis, cause it's a C function »
On pourrait te reprocher une certaine incohérence à ce niveau là. Mais je comprends la limitation technique.
« Instanciation »
Je ne comprends pas l'intérêt du mot-clé new. En plus, de ce que j'en comprends, tes types ne sont jamais créé sur la pile ? Dans ce cas, tu devrais reprendre ton benchmark sur l'instantiation, et faire la création sur la pile. Tu verras que la différence de performances est... non-négligeable (l'instantiation sur la pile est ×ばつ plus rapide que dans le tas, chez moi).
Un objet peut-il être utilisé comme un functor ?
Les objets sont polymorphiques ?
Quelle est la portée par défaut des membres d'une classe ? Public ? N'est-ce pas là une violation du principe d'encapsulation ?
« for in ranges »
C'est pratique, indubitablement. Une bonne idée serait de rajouter un type Range. Pour éviter de déclarer des ensemble en dur dans les boucles. En embarquant le pas dans le Range, évidemment.
Tu aurais pu virer switch ;)
Pas de do..while ?
« The package of a source unit is relative to the sourcepath. »
Je ne penses pas que ce soit une bonne idée. Pour tout un tas de raisons, allant de la relativité du chemin au caractère dur du chemin. Bien que le mot-clé super permette de contourner partiellement ce défaut.
Voilà pour mes quelques remarques. J'espère que ça t'aidera dans ta réflexion.