Ce progrès important est marqué par la sortie de la version 0.9.0 de rock, son compilateur, lui-même écrit en ooc. Cette version apporte son lot de nouveautés, telles que les interfaces (à la Java), les fonctions anonymes (closures, typiques des langages fonctionnels), ou encore les types énumérés (enums).
ooc est un langage de programmation orienté objet, compilé nativement, multi plates-formes (y compris la bibliothèque standard), mais surtout libre ! Compromis entre le Java/Ruby et le C, il permet de profiter d'un langage de haut-niveau sans faire l'impasse sur les performances.
Traduit en C par un compilateur source-à-source, puis compilé par un compilateur C (gcc, tcc, clang...), ooc est facile à étudier et permet d'utiliser des outils familiers tels que GDB, Valgrind etc. pour le déboguage. Parmi les nouveautés
- Les interfaces proposent une solution à l'absence d'héritage multiple, permettant à une classe d'implémenter une série de 'protocoles' qu'elle garantit savoir gérer. Par exemple, une interface 'Enregistrable' permettra de sauvegarder un objet sur le disque dur sans s'occuper de son type sous-jacent.
- Les fonctions anonymes, ou plus exactement 'closures', facilitent grandement l'implémentation d'applications orientées évènements, comme la plupart des applications graphiques, utilisant GTK+ par exemple. Elles permettent d'utiliser des variables définies en-dehors de la fonction, dans le contexte courant.
- Les types énumérés servent à déclarer des variables qui peuvent prendre un ensemble fini de valeurs. On peut déclarer une énumération des couleurs, des jours de la semaine, des différentes options d'un programme, par exemple.
Rappelons au passage que le projet cherche des volontaires pour maintenir des paquets pour Ubuntu/Debian, Fedora, Arch, Gentoo, et autres distributions Linux.
Aller plus loin
- Site officiel (41 clics)
- Téléchargements pour rock 0.9.0 (6 clics)
- L'annonce officielle de la sortie (4 clics)
- Documentation de référence (7 clics)
- Précédente dépêche LinuxFr.org sur ooc (9 clics)
# Bizarre
Posté par barmic . Évalué à 1.
Une boucle foreach sans iterateur (moi qui trouve jolie le fait d'avoir un iterateur) :
for(i in list) printf("%d\n", list[i]) // operator overloading ftwL'opérateur "as" j'ai pas bien compris son fonctionnement.
J'ai l'impression qu'il n'y a pas de fonction membres.
J'ai pas bien senti la différence entre ":=" et "=" (mais ça je le met sur le compte de mon anglais).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bizarre
Posté par Damien Thébault . Évalué à 3.
(Mais d'après le site y'a d'autres moyens de faire un for comme en Perl aussi, donc c'est un mix)
la différence entre := et = c'est que := permet d'affecter et de définir par inférence la variable alors que = c'est juste une affectation.
Par exemple :
x: Intx = 5
Est équivalent à :
x := 5Et enfin je crois que le "as" est utilisé pour caster les variables.
[^] # Re: Bizarre
Posté par Frédéric Perrin (site web personnel) . Évalué à 2.
D'après l'exemple en première page, a := b est un raccourci pour a : Type; a = b, où Type est inféré par le compilateur de façon intelligente.
Une boucle foreach sans iterateur (moi qui trouve jolie le fait d'avoir un iterateur)
Tu trouves les itérateurs jolis ? Au bon d'un moment, tu n'as pas marre d'aller chercher l'itérateur, le faire défiler à la main, vérifier s'il reste quelque chose ? Pour moi, faire défiler un intérateur est le genre de choses barbantes que mon compilateur pourrait bien faire à ma place...
[^] # Re: Bizarre
Posté par barmic . Évalué à 2.
for(String file : listFiles) { System.out.println(file) }Utilise un itérateur (que tu n'a pas à gérer à la mimine).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bizarre
Posté par Amos Wenger . Évalué à 4.
for(file in listFiles) {
file read() println()
}
'listFiles' peut-être n'importe quelle classe qui implémente Iterable, bien sûr.
[^] # Re: Bizarre
Posté par Amos Wenger . Évalué à 6.
>> Une boucle foreach sans iterateur (moi qui trouve jolie le fait d'avoir un iterateur) :
Fais-toi plaise, car
for(i in list) printf("%d\n", i)
Est exactement équivalent à:
i: Int
iter := list iterator()
while(iter hasNext()) {
i = iter next()
printf("%d\n", i)
}
>> L'opérateur as
..sert à caster entre différent types. Donc en ooc,
a := 3.14 as Int
Est équivalent à
int a = (int) 3.14f;
en C/C++/Java
>> J'ai l'impression qu'il n'y a pas de fonction membres.
Les fonctions membres sont appelées comme ceci:
monchien faitlebeau()
, pas comme
monchien.faitlebeau()
Inspiré de Smalltalk/Io, c'est plus aéré - après on aime ou on aime pas =)
# Joli
Posté par JoeltheLion (site web personnel) . Évalué à 10.
- Est-il facile d'utiliser une bibliothèque écrite en C? En C++?
- Est-il facile d'utiliser une bibliothèque ooc depuis le C? Depuis les langages dynamiques tels que python ou ruby?
- Quelle est la librairie standard d'ooc? Avez-vous l'ambition de fournir à terme une bibliothèque "batteries included" comme python? (c'est à mon avis un facteur déterminant pour le succès du langage, en dehors des qualités du langage, bien sûr!)
- Comment vous comparez-vous aux autres langages situés sur le même créneau: vala, lissaac, haskell, common lisp?
[^] # Re: Joli
Posté par Amos Wenger . Évalué à 10.
En C, oui. Il suffit de déclarer les fonctions C comme 'extern', comme ici par exemple: [http://github.com/nddrylliog/rock/blob/master/custom-sdk/lan(...)]
Pour le C++, c'est un peu plus délicat - en fait, c'est aussi facile qu'en C. C'est à dire facile si la librairie C++ en question a prévu une interface C... sinon, on cherche encore des solutions pour accéder plus facilement aux librairies C++, peut-être du côté de SWIG: [http://www.swig.org/]
Est-il facile d'utiliser une bibliothèque ooc depuis le C
Oui, même si ça fait des noms de fonctions un peu long =) du genre mon_package__MaClasse_maFonction() C'est pour ça que j'aimerais faire un générateur de headers C avec des #define qui permettraient de réduire ça à MaClasse_maFonction(), etc.
Depuis les langages dynamiques tels que python ou ruby?
Python: [http://github.com/fredreichbier/pyooc]
Ruby: à faire =)
Quelle est la librairie standard d'ooc? Avez-vous l'ambition de fournir à terme une bibliothèque "batteries included" comme python
C'est en effet un facteur déterminant. Nous avons pas mal travaillé sur notre sdk [http://github.com/nddrylliog/rock/tree/master/custom-sdk] qui contient des classes pour les entrées/sorties, le réseau (sockets, etc.), le temps, différentes collections (ArrayList, LinkedList, Stack, HashMap, etc.), les threads, etc..
Il reste des manques à combler, mais il y a pas mal de librairies sur GitHub par exemple des bindings pour CouchDB, sqlite, mais aussi curl, yajl (pour lire du JSON), curses, OpenGL, SDL, etc.
Comment vous comparez-vous aux autres langages situés sur le même créneau: vala, lissaac, haskell, common lisp?
Celui qui se compare le mieux ici est le Vala, dont la différence fondamentale est que son runtime est largement basé sur la GLib. ooc est donc une solution plus légère (les GObjects sont relativement lourd, tant niveau performance que taille de la dépendance)
Je ne connaissais pas vraiment Lissaac mais il semble que ce soit un langage orienté prototype, c'est à dire qu'au lieu d'avoir une hiérarchie de classes, on peut cloner un objet et lui ajouter des méthodes. Cela semble plus dynamique que de l'ooc - donc forcément, avec un coût à l'exécution =) Mais intéressant tout de même.
Quant à Haskell et CL, ils ont bien plus d'aspects fonctionnels qu'ooc à l'heure actuelle. Nous nous en rapprochons toutefois dernièrement (avec les closures). Les list comprehensions sont également prévues pour bientôt, afin de permettre l'évaluation paresseuse (lazy evaluation).
[^] # Re: Joli
Posté par JoeltheLion (site web personnel) . Évalué à 3.
[^] # Re: Joli
Posté par Amos Wenger . Évalué à 2.
[^] # Re: Joli
Posté par Yakulu . Évalué à 8.
- Prévoyez-vous une soumission au Shootout[1] ? Vala, dont vous parlez plus haut n'a pas, il me semble, été accepté mais les résultats paraissaient plutôt bons[2] et proches du C. Où pensez-vous que se situe OOC en termes de performances ? Peut-on d'ores et déjà l'estimer au dessus de ce qu'obtiennent Java ou C# Mono ?
- En dehors de Vala, OOC me fait également penser à Go. Certes Go n'est pas un langage objet et de nombreuses choses différencient les deux langages. Néanmoins, il semblerait que Go essaie à moyen terme de trouver un bon compromis entre performances brutes, concurrence, simplicité de développement (dont le temps de compilation) et batteries incluses. Comment OOC se positionne-t-il au niveau de la concurrence ? Par rapport au développement, si je comprends bien, cela se passe comme Vala : une première compilation ou traduction vers du C puis une seconde phase par un compilateur C. Est-ce que cela ne risque pas de rendre le développement de programmes complexes assez long ? (bien des aspects m'échappent certainement, étant donnée mon inculture des langages compilés et de leurs écosystèmes, d'où la question !)
- Il existe un micro-framework[3] orienté développement Web pour OOC; imaginez-vous qu'OOC puisse être employé dans ce cadre ou n'est-ce pas vraiment le but ?
- Ruby a RoR, Vala a l'environnement Gnome, Go a Google et une équipe renommée - je sursimplifie, veuillez m'en excuser - pensez-vous à orienter consciemment OOC vers un certain type de développement (bases de données, jeux vidéo... ) ?
En tout cas bravo.
1 : [http://shootout.alioth.debian.org/]
2 : [http://code.google.com/p/vala-benchmarks/wiki/BenchResults]
3 : [http://github.com/joshthecoder/ooc-web]
[^] # Re: Joli
Posté par Amos Wenger . Évalué à 8.
- Shootout: quelqu'un vient de suggérer la même chose sur IRC =) C'est à considérer. Cependant, il y a des énormes possibilités d'optimisations qui ne sont pas encore implémentées (je pense notamment à la spécialisation de types génériques au temps de l'exécution, pour les initiés), et donc je ne sais pas trop comment ooc se comparerait si on utilise beaucoup les collections. A suivre, je dirais.
- Rendre le développement des programmes long? Au niveau des temps de compilation? Pour cela il y a la recompilation partielle, qui permet de recompiler uniquement les modules qui ont changé. C'est un gain de temps très apréciable. D'autre part, nous envisageons de développer une REPL, ce qui permettait de modifier un programme pendant son exécution et ainsi avoir quasi le même confort qu'un langage interprété. Au niveau de la concurrence (e.g. le parallélisme, pas la rivalité ^^), c'est un sujet qui soulève bien des discussions dans la communauté. Nous ne sommes pas fixés sur une solution définitive, nous préférons nous donner du temps pour expérimenter et tester les différentes variantes afin de choisir celle qui nous semble la meilleure.
- Absolument, l'utilisation d'ooc côté serveur est tout à fait intéressante, et il semble y avoir une vague d'intérêt dans ce sens-là (nouveaux contributeurs à ooc-web/ooc-couchdb, etc.)
- Pour rebondir sur la question précédente, ooc a plutôt vocation de rester un langage généraliste. Personellement j'essaie (entre autres) d'explorer son utilisation dans le développement de jeux vidéos (en conciliant une grande flexibilité avec la performance), mais le langage reste un bon substitut à Java/C# dans la plupart des cas, si l'on souhaite un runtime plus léger et une compilation native. ooc présente aussi une alternative intéressante au C sur les plateformes embarquées, même s'il reste des progrès à faire de ce côté là, des collaborations sont en cours pour mieux adapter ooc pour l'embarqué, notamment un sdk allégé.
Merci pour les encouragements, quoi qu'il se passe, nous continuerons à vous tenir au courant!
[^] # Re: Joli
Posté par case42 (site web personnel) . Évalué à 4.
[^] # Re: Joli
Posté par gasche . Évalué à 6.
Quel est le lien entre les 'list comprehensions' et l'évaluation paresseuse ?
[^] # Re: Joli
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Il n'y a heureusement aucun surcout à l'exécution. La preuve est que Lisaac a été premier pendant un moment dans le langage shoutout, avant que les implémentation C et C++ soit modifié.
"La première sécurité est la liberté"
[^] # Re: Joli
Posté par auve . Évalué à 4.
Par contre, il y a un algorithme de compilation en temps exponentiel et pas de compilation séparée, non ?
[^] # Re: Joli
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Sachant que compiler 50 000 lignes de code prend quelques dizaines de secondes, la "constante" est faible.
C'est un des axes d'améliorations du langages : passer à l'échelle du millions de ligne de code, et prévoir un système pour compiler à part le module en court de développement pour diminuer le temps de recompilation (le temps le plus long est pris par gcc).
"La première sécurité est la liberté"
[^] # Re: Joli
Posté par Ontologia (site web personnel) . Évalué à 8.
Effectivement, il est à prototype et héritage multiple, donc le parent s'affecte comme un slot normal que tu peux changer ou tu veux dans le code. Le parent a une existence physique propre (ou pas, car il y a 4 formes d'héritages différents en Lisaac).
Concernant le coût du dynamisme, il n'y en a pas, d'une part parce que le compilateur n'utilise pas de VFT contrairement au votre *
Lisaac** utilise des branchements dichotomiques, et transforme 99,6% (mesuré sur le compilateur, 400 000 appels, de l'héritage statique et dynamique dans tous les sens) des appels polymorphique en appel statique.
Conclusion : tu n'as aucun cout pour le dynamisme. Et heureusement parce que dans ce langage, le if est un point de liaison dynamique, ne pas le faire serait catastrophique.
Les VFT c'est lent, et ça a un cout énorme à l'exécution car :
- Tu ne peux inliner
- Le processeur ne peut pas optimiser car tu fais un jump indirect sur du code
--> Tu dois garder tout tes objets en mémoire
--> Certains objets ne peuvent décemment pas l'être pour des raisons de perfs. Par exemple, dans IsaacOS, et dans la GUI de la lib lisaac, par exemple, PIXEL est un objet, qui a des enfants PIXEL_16, PIXEL_8, PIXEL_32, etc.... Avec un modèle à VFT comme dans ooc, ça ruine les performances, parce que ça t'oblige à utiliser des VFT pour chaque appel de fonction sur tes pixels...
Conseil : regarde ce qu'a fait Dominique Colnet dans son smarteiffel : c'est implémentable en ce qui vous concerne, parce que l'algorithme d'analyse de flot de Lisaac, c'est une autre paire de manche (surtout que votre langage est gros, ce qui simplifie pas la tâche).
Et bon courage, parce que je sais de quoi je parle, et ça rend solidaire ;-)
*
Ce code :
Animal: abstract class {
shout: abstract func
}
Dog: class extends Animal {
shout: func { "Woof, woof!" println() }
}
Cat: class extends Animal {
shout: func { "Meoooww!" println() }
}
poke: func (animal: Animal) {
animal shout()
}
poke(Dog new())
poke(Cat new())
Donne lieu à une VFT dans le C produit :
void test__Animal_shout(test__Animal* this) {
((test__AnimalClass *)((lang_types__Object *)this)->class)->shout((test__Animal*)this);
}
**C'est expliqué ici http://www.dailymotion.com/video/xba8ij_1-8-presentation-du-(...) ou dans les suivantes.
Tu as la vidéo des JM2L aussi, plus courte et synthétique.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Joli
Posté par Guillaumito (site web personnel) . Évalué à 7.
C'est quoi le créneau de ce langage ?
[^] # Re: Joli
Posté par alice . Évalué à 4.
Le créneau des langages libres proche du C, orientés objets, avec types statiques?
Dans ce domaine, e développeur libre a le choix entre un Java bloated et un Mono piégé.
Vala et ooc sont donc les bienvenus!
[^] # Re: Joli
Posté par auve . Évalué à 4.
Dans ce domaine, e développeur libre a le choix entre un Java bloated et un Mono piégé.
Hum, tu trouves que Java et C# sont « proches de C » ? J'aurais plutôt cité C++, D, Go...
# Canal IRC en français o/
Posté par Amos Wenger . Évalué à 4.
# Un petit avis
Posté par DrBuenol . Évalué à 1.
_Une syntaxe qui force le style à la python me semble le choix le plus judicieux.(j'en voit que des avantages)(enlever les "{",passage de ligne obligé,...)
_L'absence de "." pour appeler les membres (alors que c'est une habitude dans la majorité des langages) rend celui ci largement moins lisible.
_J'aurai bien aimé un seul opérateur d'affectation (":=") l'a il va y avoir confusion et on perd l'intérêt d'enlever "="(confusion avec "=="). (oui,totalement supprimer "=")
_Le GC: ne peut pas être desactivé apparament
_Librairie standard dépendante du C?
En tout cas de trés bonnes idées sur les autres choses et une trés bonne initiative pour essayer de remplacer le viellisant C
[^] # Re: Un petit avis
Posté par Sebastien . Évalué à 3.
[^] # Re: Un petit avis
Posté par Amos Wenger . Évalué à 1.
Non =)
[^] # Re: Un petit avis
Posté par Sebastien . Évalué à 4.
[^] # Re: Un petit avis
Posté par Amos Wenger . Évalué à 4.
'use math' permet.. d'utiliser la librairie math, donc d'avoir les bonnes options pour le compilateur C, telles -lm (définies dans le fichier math.use)
'import math' importe tous les types, fonctions, variables dans le contexte courant.
'import math into math' importe tout dans un namespace ce qui permet de faire ce que tu voulais faire en python.
Le code correct est donc:
use math
import math
x := sqrt(100)
et
use math
import math into math
x := math sqrt(100)
Note que tu peux donner n'importe quel nom au namespace après le "into", tu peux donc l'appeler "sysmath" par exemple pour ne pas confondre si tu as ton propre module math.
[^] # Re: Un petit avis
Posté par Amos Wenger . Évalué à 2.
C'est vrai, ça choque. De là à dire que c'est "incohérent" je ne sais pas.. peu familier j'admet =)
_Une syntaxe plus à la python
A ce point, il est un peu tard pour changer aussi lourdement la syntaxe. Toutefois, jette un oeil à http://cobra-language.com/ ça pourrait t'intéresser ma foi =)
_L'absence de "." pour appeler les membres
Il y a des précédents, notamment Smalltalk et Io. Après, c'est une question de goût et aussi d'habitude. Ça choque au début, mais au final beaucoup préfèrent.
_Un seul opérateur d'affectation
Débat millénaire, comme d'hab! L'opérateur ":=" sert a déclarer *et* assigner une variable, ce qui est tout à fait logique, si on part de:
i : Int = 42et qu'on enlève le type, on obtient
i := 42Voilà d'où vient cet opérateur.
Pourquoi ne pas avoir permis
_Le GC
.. peut être désactivé, un petit -gc=off, et c'est réglé =) (Bon bien sûr la librairie standard n'est pas prévue pour donc ça c'est si tu veux faire ton propre SDK. Ce qui se fait tout à fait, voir le projet oos de tsion sur GitHub)
_Librairie standard dépendante du C?
L'implémentation courante oui mais rien n'empêche une implémentation alternative, ça s'utiliserait de la même manière.
# Ook?
Posté par karteum59 . Évalué à 5.
http://fr.wikipedia.org/wiki/Brainfuck#Ook.21
# Cross compilation?
Posté par alice . Évalué à 3.
En effet, fournir des binaires pour différents OS est une tâche pénible avec tous les langages compilés que je connais, car il faut soit disposer de tous les OS avec un environnement de développement, soit être un pro du makefile.
Ce serait bien de pouvoir tout générer avec un simple :
ooc --platforms=linux,macosx,windows ...
[^] # Re: Cross compilation?
Posté par Amos Wenger . Évalué à 3.
Bien que je n'aie que peu d'expérience dans le domaine (pour rock 0.9.0, nous avons compilé les binaires sur chaque OS), voici ce que je peux dire:
1) rock dispose de l'option '-driver=make', ce qui permet d'exporter le programme compilé sous forme de sources C dans un dossier build/, avec un Makefile multi-plateforme. Ce qui réduit "l'environnement de développement" nécessaire à.. gcc + les librairies C utilisées.
2) le code C produit par rock est le même quel que soit l'OS sur lequel on le compile. Ce sont des #defines à l'intérieur du code C qui utilise l'une ou l'autre partie du code.
3) Pour ce qui est de la compilation cross-platform, il faut dans tous les cas un cross-compilateur C installé, non? Il me semble que des distros comme Gentoo rendent cela partiulièrement facile, je ne sais pas pour les autres.
A noter qu'on peut spécifier à rock de choisir la version de gcc qu'on veut, par exemple -gcc=i686-pc-linux-gnu-gcc
# Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par gasche . Évalué à 10.
Je pense donc qu'ooc est une bonne idée (écrire un langage, c'est amusant, donc c'est toujours une bonne idée), et je trouve l'aspect communautaire sympa.
Par contre, je trouve l'approche pas très rigoureuse. Le langage n'est décrit nulle part. J'aimerais bien savoir, par exemple, comment fonctionne l'algorithme d'inférence des types. Je suspecte que c'est un algorithme très ad-hoc (les sources par d'un "funny score system", hmm...); je trouve un peu dommage de parler d'inférence (on pense tout de suite aux langages avec une vraie inférence de type) pour un truc au final plutôt limité, et surtout imprévisible parce que non spécifié : on est un peu déçu.
De même, je trouve dommage de présenter comme "pattern matching" un sucre syntaxique qui ajoute implicitement des tests d'égalité à une variable de 'switch'. Le vrai pattern matching ( http://fr.wikipedia.org/wiki/Filtrage_par_motif ) est beaucoup plus puissant que ça, donc quand on se rend compte de ce que c'est en ooc, on est déçu.
Dans ce contexte (l'inférence n'est pas une vraie inférence, le pattern matching n'est pas un vrai pattern matching, j'espère que vos closures sont de vraies closures !), je pense qu'on peut difficilement décrire ooc comme un langage "functional-ish" : vous avez des fonctions imbriquées et anonymes, c'est bien, c'est mieux que le C, mais le langage ne me semble pas fonctionnel pour autant.
Je pense que la documentation manque un peu de rigueur. J'aimerais bien une description précise et globale du langage quelque part : une description de la syntaxe et de la sémantique du langage. Je pense qu'il serait aussi important de détailler quelque part les raisons qui vous ont poussé à lancer ce projet, une comparaison avec les concurrents (Vala ?), et surtout quelques défauts (temporaires et conceptuels) du langage : c'est bien de présenter ce que vous faites bien, mais il faudrait aussi essayer de dire ce qui est moins bien.
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par Amos Wenger . Évalué à 4.
Voici une grammaire formelle: http://github.com/nddrylliog/nagaqueen/blob/master/grammar/n(...)
Effectivement l'inférence est limitée, puisqu'on interagit avec le C et que, d'autre part, on aime bien profiter d'une certaine sûreté (type checking). Pour du tout-inféré, voir ML ou quelque-chose du genre.
Quant au manque de documentation, je suis le premier à le dénoncer. C'est réellement une question de gestion du temps. Tant que le langage était l'affaire de quelques-uns dans la communauté nous pouvions nous permettre de se limiter à la culture orale/IRC. C'est maintenant qu'apparaît la nécessité d'écrire une *vraie* documentation, et croyez-moi, il y a des efforts dans ce sens-là =)
Pour ce qui est du pattern matching, c'est également prévu. Mais de nouveau, il faut bien commencer quelque-part, n'est-ce pas? Nous préférons exposer ce qui est déjà fait tout en restant dynamiques et en publiant régulièrement des versions, plutôt que d'en faire un projet de recherche, de lâcher une version "finie" sur un FTP et de ne plus jamais y toucher (non, je ne vise personne).
En bref - tes critiques sont valides, je les reconnais, nous sommes au courant, et on y travaille =) Merci quand même de ton attention.
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 0.
Non, voici un fichier utilisé par le parser.
C'est pas ce que j'appelle une grammaire formelle (et ça participe donc aussi au manque de documentation.)
Et sinon, vous faites quoi dans la vie ? Je veux dire (sérieusement) : « ce langage est-il développé par des gens qui (f)ont un doctorat en sémantique ? » ou juste par une bande d'amateurs qui se fait plaisir ?
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par Amos Wenger . Évalué à 6.
http://github.com/nddrylliog/nagaqueen/blob/master/grammar/n(...)
EBNF c'est tellement années 1970, il faut se moderniser un peu, vraiment, on a inventé ça depuis: http://en.wikipedia.org/wiki/Parsing_expression_grammar
(Et sinon, le doctorat c'est peut-être pour dans quelques années, mais pour ma part en Informatique à l'EPFL - sauf que je vois absolument pas l'intérêt de la question..)
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par Amos Wenger . Évalué à 4.
Vous connaissez beaucoup de langages amateurs qui sont self-hosting? Si on s'y était vraiment pris au petit bonheur la chance, on en serait jamais arrivé là. "Oh vous savez, on a empilé 13500 lignes de code jusqu'à ce que ça se compile"..
Même si le manque de documentation est réel (mais là encore, si vous n'avez aucunement l'intention d'en faire usage - en quoi cela vous dérange-t-il?), cela me semble être une excuse pour ne pas creuser plus profond. En restant en surface, c'est facile de critiquer - le site est daté, les développeurs ont le sens de l'humour (donc ne se prennent pas trop au sérieux justement) - en passant à côté des qualités du langage et de l'implémentation, ce dont il serait tellement simple de s'en rendre compte en prenant la peine de l'essayer..
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par whity . Évalué à 8.
Un langage massivement utilisé comme php souffre encore énormément de l'amateurisme complet qui a donné lieu à sa naissance. Un langage pourtant très professionnel comme C++ s'est gardé pendant des années une restriction débile sur le double-chevron des génériques, parce que les gens ont loupé l'implication grammaticale que cela imposait.
Bref, formaliser plus les choses, ça me semble une étape importante au vu de l'avancement de votre projet.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par Amos Wenger . Évalué à 3.
Toujours dans la série des nouvelles que je ne devrais pas annoncer si tôt, il y a un projet de livre exhaustif sur ooc, et de redesign complet du site web.
Un vrai spec final naîtra avec la sortie de rock 1.0, pour éviter d'avoir trop à réécrire d'ici là (mais rien ne nous empêche de faire un brouillon d'ici là - tant que les gens sont conscients que des choses peuvent encore changer)
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à -1.
Tu t'adresses pas à moi en parlant de critique là, j'espère ?
Un fichier de code n'est pas ce que j'appelle une grammaire formelle, surtout s'il faut chercher la grammaire au milieu du bruit du fichier. Le code, c'est pas formel pour deux sous. C'est pas une critique du langage ou quoi que ce soit, c'est un fait : le formalisme repose aussi dans la présentation ; dans un fichier à part, par exemple comme sur [http://people.csail.mit.edu/jaffer/r5rs_9.html]
Ensuite, je demandais honnêtement quel était votre compétence/connaissance. En fonction de votre expérience je sais que je ne trouverais pas les mêmes procédés d'implantation du langage (typiquement au niveau de la représentation interne des objets ou le choix du système de type). Je n'ai *rien* dit sur le langage lui même, vu que je n'ai pas assez lu la doc ni les exemples.
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par gasche . Évalué à 7.
Le parser est un bon départ : tu pourrais le prendre à l'identique, enlever toutes les productions (garder que la partie "grammaire"), et mettre ça sur le site, ça serait déjà un bon progrès.
Ce que j'ai cherché sur votre site, c'est l'analogue de ce document pour Go : The Go Programming Language Specification.
Dans un deuxième temps, je serais intéressé par un condensé d'informations sur les nouveautés du langage et les choix que vous avez fait. Pour Go, c'est ce document : Language Design FAQ.
J'ai effectivement remarqué le sens de l'humour (entre nous, je me demande si le "THREE FUCKING TIMES" ne risque pas de rebuter certains anglophones, c'est quand même un peu vulgaire), ça a son charme, mais je trouve le texte en page d'accueil trop long et trop verbeux : quand on regarde 5 minutes un nouveau langage, on a besoin de quelque chose de plus dense et informatif. Le "Poignant guide to Ooc", c'est pour dans un second temps.
Par contre, il faut retenir les exemples de code source, c'est une très bonne idée.
Bref, je pense qu'une documentation concise mais précise et complète serait le meilleur moyen, justement, d'éviter les remarques superficielles, en permettant aux gens d'avoir un aperçu en profondeur du langage en un temps raisonnable.
Parce que "prendre la peine de l'essayer", c'est une bonne idée, mais pour pouvoir tout essayer il faut commencer par se renseigner sur tout ce qu'il y a, justement, à essayer; et si on essaie mais passe à côté d'une partie des fonctionnalités, c'est dommage.
Pour revenir au "se prend trop au sérieux" (opposé à l'humeur et la détente dans les docs) : ce que je voulais dire, c'est que quand on va sur le site web, on lit en gros (j'exagère volontairement le trait) « ooc est un roksor langage qui se base sur des techniques ultra-modernes, s'inspire de C, Smalltalk, Java, Ruby et Haskell, qui va résoudre tous vos problèmes en conservant des performances de brute »
On peut considérer ça comme de l'humour, mais moi qui suis bonne poire, je me suis sérieusement attendu à voir tout ce que vous évoquiez dans ce descriptif, et donc forcément j'ai été un peu déçu.
Je pense qu'il vaut mieux se contenter des quelques points clés de votre langage, sans faire de la surenchère.
Par exemple, ooc est compilé vers du C, ça a l'avantage de vous garantir une bonne compatibilité, et c'est bien d'en parler. Par contre, c'est moins bon pour les performances et/ou l'extensibilité du langage : vous ne pouvez plus utiliser un GC exact, difficile d'optimiser la tail-recursion, etc. Il faut en parler aussi.
PS : moi non plus je ne comprends pas la question sur les "doctorants en sémantique"; il n'y a pas besoin d'être un spécialiste de la théorie pour monter son petit langage.
Ce que sous-entendais peut-être la question, c'est qu'il y a eu beaucoup de recherche sur les langages de programmation depuis l'avènement du C, qui est malheureusement assez soigneusement ignorée par la plupart des langages "modernes" de cette catégorie (D, Go, etc.). C'est vrai que c'est dommage, et ooc ne déroge pas à la règle.
Après, moi je trouve que, dans le cas de ooc, c'est compréhensible et même tout à fait normal. C'est ce que j'appelle le point de vue "langage amateur" : il s'agit de se faire plaisir, de s'intéresser à l'implémentation d'un vrai langage, de réfléchir sur certains points (la syntaxe par exemple), etc. Pas de révolutionner le domaine.
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par gasche . Évalué à 2.
Go Language Specification : http://golang.org/doc/go_spec.html
Go Language Design FAQ : http://golang.org/doc/go_lang_faq.html
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
Il n y a pas besoin, non. Mais si tel est le cas, autant le dire. En effet, les raisons qui poussent a creer un nouveau langage (ou a reimplanter un langage existant) ne sont surement pas les memes.
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par gasche . Évalué à 8.
Je trouve que ça manque un peu de tact quand tu évalues le travail de quelqu'un de lui demander d'abord s'il est spécialiste dans le domaine. Soit il l'est, et normalement on s'en rend compte, soit il ne l'est pas et il pourrait se vexer. On peut aussi bien se comporter en fonction du travail seulement, et pas de la personne, et ça évite ce genre d'embarras.
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Le thread parle de langage amateur, je demande si c'est le cas ou non : "etes vous des amateurs ou pas ?"
Ca se voit pas forcement, loin de la. Quand un gars comme Joe Marshall se fait traiter de noob [http://funcall.blogspot.com/2010/04/education-of-jrm.html] je me dis que c est pas toujours evident, non...
T as des langages simples fatis par des pros, et l inverse aussi. Et encore une fois, en fonction de l historique de chacun, on peut se faire une idee de la maniere utilisee pour developper le langage. S il n est pas un pro, il y a peu de chances qu il aie des fermetures avec partage de code (comme dans (\x. if x then 2 else (\y. x+y))) ou` une seule fermeture (avec double pointeur de code) peut suffire. Pour les gens qui regardent juste la syntaxe, ca change rien. Pour moi, ca change tout, car c'est cette partie qui m interesse. Le langage en soit, je m'en tape. Je ne suis ni pour, ni contre, et je n emet aucune critique, aucun jugement a son egard : je n'ai qu a peine survole' la page d'accueil !
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par Amos Wenger . Évalué à 4.
Concrètement qu'est-ce qui t'as déçu par rapport à la description de la page d'accueil?
@utf8powa:
« Release early, release often » -- Eric Steven Raymond, The Cathedral And the Bazaar
« Premature optimization is the root of all evil. » -- Donald Knuth, Computer Programming as an Art
« Version 1 sucks, but ship it anyway » -- Jeff Atwood, Coding Horror
« One must learn by doing the thing; for though you think you know it, you have no certainty, until you try » -- Sophocles
Et si au lieu de voir les petits détails faciles à régler pour une version ultérieure tu voyais le côté positif pour changer?
L'implémentation des fermetures à double pointeur, c'est trivial. Nous avons implémenté le plus difficile - les femetures avec partage de code (peu importe le nom qu'on leur donne), ce qui permet de les passer comme pointeurs vers des fonctions à des fonctions C.
On pourrait penser que le numéro de version (0.9) donnerait une indication quand à la nature *pas terminée* du langage, mais manifestement, non, on aurait pu mettre les décimales de pi (cf TeX) ça aurait été pareil ^^.
À part ça - le monde est plein à craquer de langages universitaires, par des universitaires, pour des universitaires. Qui sont dans leur tour d'ivoire, confortablement installés sur leur modèle théorique qui est d'une élégance qu'ils sont les seuls à pouvoir apprécier.
Et puis il y a ceux qui essaient de faire des choses utiles. Non pas que le formalisme soit inutile, ou qu'il n'influence pas l'évolution des langages de programmation (quoique comme le rappelle Bluestorm la plupart des 'nouveaux' langages ne sont que des anciens concepts réchauffés). C'est juste que pour réaliser quelque-chose de concrèt et d'utile, il faut maintenir un équilibre entre l'amateurisme et le formalisme.
En effet, vouloir révolutionner le domaine de la programmation - c'est bien, mais honnêtement je n'y crois plus trop. Même les langages les plus acclamés dernièrement au niveau conceptuel (Scala, Clojure..) me semblent en grande partie reprendre des concepts qui existent depuis une dizaine d'années.
Je fais partie de ces gens qui, sans cracher sur les diplômes, ont commencé à programmer par passion, et continuent à la faire pour la même raison. Je pourrais avoir le plus beau formalisme du monde, cela ne me rendrait pas aussi heureux que de voir des projets fleurir comme des frameworks web, des jeux vidéos, des bots irc, des IDEs, etc., etc. parce que j'ai fait des compromis pour être plus facile à interagir avec le C.
Pour qu'un langage ait du succès, il ne suffit pas d'avoir un doctorat en sémantique. Il faut avoir la patience de coordonner l'effort dans le bon sens jour après jour. Il faut prêter l'oreille aux rapports de bogue de la communauté entière, pas juste de ceux qui nous arrangent. Il faut savoir tirer le meilleur de chacun des contributeurs, et il faut savoir dire "bon, allez, on sort une version" de temps en temps.
J'espère que vous comprendrez mon point de vue. Si tel n'est pas le votre, bonne nouvelle, il existe des tas de langages fait précisément pour vous =) Le monde est vaste, je suis pour la diversité. Le plus important pour moi est d'en profiter. Le jour où je n'aurai plus aucun plaisir à travailler sur ooc, je mettrais la clé sous la porte.
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par lasher . Évalué à 10.
« À part ça - le monde est plein à craquer de langages universitaires, par des universitaires, pour des universitaires. Qui sont dans leur tour d'ivoire, confortablement installés sur leur modèle théorique qui est d'une élégance qu'ils sont les seuls à pouvoir apprécier.
Et puis il y a ceux qui essaient de faire des choses utiles. »
Certes, juste derrière tu dis que « ah mais non, le formalisme c'est bien aussi hein » (oui bon, je simplifie), mais cette phrase, là, elle n'a pas lieu d'être. Parce que tu vois, LISP, OCaml, tous ces langages plus ou moins multi-paradigmes, plus ou moins fonctionnels, le lambda-calcul, toutes ces conneries inutiles inventées par des universitaires, tout le monde en bouffe plus ou moins tout le temps sans le voir. Genre Java, c'est rempli de machins pour la sûreté des types [1]) ; C# intègre de plus en plus de constructions directement empruntées aux langages fonctionnels; C++ veut intégrer les lambda-fonctions, etc.
Et tout le monde, à un moment donné (dans l'industrie, celle qui « fait des vrais choses » bien sûr) a qualifié ces langages de « pas utilisables par le commun des mortels », etc.
Parce que des langages faits « par et pour des universitaires », crois-moi, j'en ai connus quelques uns, mais -- oh surprise ! -- lesdits universitaires le savent. Dingue non ? En fait, très souvent, un universitaire crée un langage non pas parce que ça le fait kiffer à mort (il est spécialiste en langages, du coup fabriquer une grammaire et utiliser lex/yacc ou LISP ou OCaml pour fabriquer une nouvelle syntaxe, il sait faire sans trop se forcer).
Non, il fait ça pour donner une preuve de concept [2].
« C'est juste que pour réaliser quelque-chose de concret et d'utile, il faut maintenir un équilibre entre l'amateurisme et le formalisme. »
Le truc, c'est qu'à partir d'un certain moment, si le langage devait vraiment être intéressant, plaisant à utiliser, etc., bref, si une communauté un peu plus grosse devait s'intéresser à ton bébé, tu vas devoir finir par réellement formaliser ton langage. Des gens potentiellement intéressés pour aider à développer le langage, je suis persuadé que tu vas en trouver plein. Des gens intéressés et qui vont proposer des modifications pertinentes, tu vas peut-être en avoir qui se compte sur les doigts des deux mains. Mais il y a de fortes chances pour que ces derniers arrivent jusqu'à toi, ils aient besoin d'avoir des repères qui leurs parlent. Genre euh ... un langage commun qu'on appellerait ça. Oui, mais lequel utiliser ? Ah ben, si on utilisait la BNF ? Par exemple, hein. ;-) [3]
« Je fais partie de ces gens qui, sans cracher sur les diplômes, ont commencé à programmer par passion, et continuent à la faire pour la même raison. Je pourrais avoir le plus beau formalisme du monde, cela ne me rendrait pas aussi heureux que de voir des projets fleurir comme des frameworks web, des jeux vidéos, des bots irc, des IDEs, etc., etc. parce que j'ai fait des compromis pour être plus facile à interagir avec le C. »
Tu sais, quand tu finis par arriver au niveau de la thèse, t'as intérêt à un minimum aimer ce que tu fais (j'en connais pour qui ce n'est pas le cas, mais c'est quand même super rare). Et je mets la barre très haut pour le « minimum ». Donc t'inquiète, la passion est là. [4].
En temps normal je serais d'accord avec toi, « les diplôme on s'en fout » [4]. Quand il s'agit du design d'un nouveau langage, je vois deux cas de figures : l'amateur éclairé (dont tu fais partie), et le « pro » (souvent un de ces sales universitaires, ou un ingé de recherche avec très souvent un doctorat, hou la honte, encore un mec qui sert à rien [5]). L'amateur éclairé se décline là encore en deux catégories : celui qui a pas mal de bouteille concernant la prog, les concepts en informatique, etc., bref qui a lu des articles/des bouquins concernant l'info, qui se passionne, etc. Techniquement, je lui fais confiance pour comprendre les concepts, et savoir comment les appliquer dans un langage. Et y'a aussi l'inventeur de MultiDeskOS, le meilleur programme de tous les temps, qui fait le café, enfin promis, dès que le soft dépassera le stade pré-pré-alpha. Celui-là est très certainement aussi passionné, mais n'a pas forcément la culture informatique pour réellement arriver à quoi que ce soit. [6]
« Pour qu'un langage ait du succès, il ne suffit pas d'avoir un doctorat en sémantique. Il faut avoir la patience de coordonner l'effort dans le bon sens jour après jour. »
Non, pour qu'un langage ait du succès, il faut juste y mettre les moyens logistiques et financiers qui vont bien. Le langage D est très intéressant par exemple, mais on entend bien plus parler de C# ou Java (qui a mis le temps pour s'imposer, certes). Dans notre microcosme « libriste » (quel affreux mot), on est plus curieux quant aux nouveaux langages, mais 'achement moins nombreux que la masse laborieuse des informaticiens. Du coup, il faut réellement que le langage ait une valeur très ajoutée pour qu'il ait du succès hors de son petit monde du Libre. [7] Les exemples les plus flagrants sont certainement Perl (dans les années 90), PHP, Python, et dans une moindre mesure Ruby.
[1] Cf. le bouquin de Pierce: Types and Programming Languages par exemple.
[2] Hou que c'est moche la traduction mot-à-mot, personne n'aurait une proposition plus idiomatique ?
[3] Ou n'importe quel autre type de formalisme, mais un machin que les gens « du métier » comprennent. Et par métier, je veux simplement dire des gens qui trifouillent le domaine, de façon pro ou amateur.
[4] Soyons bien d'accord : je me fous des diplôme d'un programmeur 99% du temps. J'ai assez eu de boulets en binôme pendant mes études pour des projets info pour savoir que le diplôme n'indique absolument rien en ce qui concerne les compétences techniques d'une personne. Au contraire, je connais des gens qui ont pas loin de 10 ans de moins que moi, et qui sans aucun diplôme sont sans doute bien meilleurs développeurs que moi.
[5] Je suis en plein décalage horaire, et sur une autre planète, il est encore certainement vendredi.
[6] Concernant les universitaires, il y a aussi deux sortes : celui qui va savoir tout théoriser mais n'approchera jamais un clavier, sauf pour rédiger un article en latex -- et encore -- et celui qui sait aussi coder. Généralement, on se retrouve avec un directeur de recherches qui a su coder, mais délègue désormais cette tâche aux grouillots^Wthésards.
[7] Je ne porte aucun jugement sur ton langage, je ne le connais pas.
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par Amos Wenger . Évalué à 3.
J'avoue, je fatigue - la politique c'est pas ma passion. Sincèrement désolé.
« toutes ces conneries inutiles inventées par des universitaires, tout le monde en bouffe »
20 ans après, oui. En quoi est-on en désaccord? Je me tiens au courant de la recherche autant que possible, les idées sont bonnes à prendre, mais effectivement je prie pour que les 'universitaires' qui savent coder pour de vrai (pas juste des LaTeX-eux) copulent, se multiplient - que dis-je, envahissent la terre.
« Ah ben, si on utilisait la BNF ? »
Pourquoi pas, mais ça représente un effort (donc un temps) non-négligeable, surtout en ayant déjà une grammaire PEG - tout aussi formelle, mais un peu plus moderne.
Le fait est que pour l'instant je considère qu'ooc est encore dans une phase ou je fais (tiens donc) de la recherche. Je cherche comment implémenter efficacement de l'analyse de fuite[1] afin de pouvoir optimiser les programmes sans que le programmeur doive choisir où allouer ses classes et tout gérer à la main (cf. C++), je cherche une solution permettant d'avoir des classes et des fonctions génériques sans avoir un surpoids significatif des binaires (cf. C++) sans pour autant sacrifier la performance (en permettant la spécialisation de types/fonctions génériques à l'exécution). Je cherche, comme tous les langages contemporains, une solution simple et puissante au problème de la concurrence.
Seulement, je préfère partager le peu qu'on a déjà réalisé. Ce qui nous permet d'avoir, par exemple, des réactions très intéressantes et très instructives (ce fil de discussion, par exemple), d'avoir des idées, de liens, des recommandations de voir comment tel ou tel autre langage le fait, de se référer au travail de Machin pour en savoir plus, etc. (C'est finalement à ça que ça sert, "Release early, release often")
Au-delà de faire les premières pages des sites de news, sortir une version ne me fait pas plaisir. C'est toujours une grande paire de claque, qui permet justement - après avoir encaissé le coup - de se remettre en piste avec une longue liste de bons tuyaux et de commentaires constructifs (dans la plupart des cas). Cela permet de rencontrer des gens, parler de là où ils travaillent, de leurs besoins et d'en quoi le langage les intéresse potentiellement et ce qui lui manque encore pour leur être vraiment utile.
Je n'ai ni les moyens, ni l'envie de promouvoir à grand coup de fric et de logistique un langage qui n'en vaut pas la peine. Je suis de tout coeur d'accord avec toi - « il faut réellement que le langage ait une valeur très ajoutée pour qu'il ait du succès hors de son petit monde du Libre. » C'est justement parce que l'exigence est si grande qu'il est si bénéfique de travailler dans ses conditions-là. De mériter sa place, ou d'être déchu. Au final, ce seront les mérites techniques du langage qui l'emporteront, ou pas. Telles sont les règles du jeu.
Toutefois, s'il n'y a pas de versions qui sortent, s'il n'y a pas d'annonces, s'il n'y a pas une certaine exposition au public du langage, je dirais même une certaine démocratisation, alors le langage n'a aucune chance d'un jour attirer un acteur ayant les moyens de financer son succès. C'est un mal nécessaire.
On nous reproche de tenter d'attirer les débutants sur notre page d'accueil (cf. commentaires sur reddit - « Don't explain to me that this is a for loop, etc. »), mais c'est justement eux qui pourront le plus souvent juger de la simplicité du langage. Un pro comme tu dis, n'aura aucune difficulté à se faire au système le plus complexe. Mais si même le plus naïf, le plus innocent des programmeurs débutants arrive à faire sens d'un programme sans connaître le langage auparavant alors nous aurons déjà atteint une partie de notre objectif concernant la syntaxe.
[1] Amen, mon frère - la traduction mot-à-mot c'est atroce. [http://en.wikipedia.org/wiki/Escape_analysis]
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par Thomas Douillard . Évalué à 5.
Ils verront des trucs que le débutant ne verra pas : typiquement les débutants ont toujours tendance à être rebutés par les sytèmes de typage qui peuvent être très strict, quand un pro pourra te parler des algos d'inférences de types qui marchent bien pour vérifier les types sans que le programmeur ait à trop se fatiguer à déclarer la moindre variable triviale.
Pour les problèmes de concurrences aussi, j'imagine qu'il y a un état de l'art assez conséquent en recherche, et dans des langages industriels aussi, dans lesquels il y a des idées intéressantes pour que le programmeur débutant soit heureux, et qu'il te dise "waaah c'est trop cool ton truc" sans avoir conscience du travail et des écueils à éviter pour arriver au résultat ...
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par Amos Wenger . Évalué à 2.
J'ai été invité au Emerging Language Camp [http://emerginglangs.com/] pour présenter mon travail sur ooc. Seul petit problème, c'est à Portland et je n'ai pas vraiment les moyens d'y aller. Je recommande à tous ceux qui sont intéressés par les nouveaux langages et qui ont les moyens d'y aller - c'est rempli de conférenciers passionnants =)
Il est utile d'avoir des débutants pour jauger de la simplicité du langage, mais ce n'est effectivement en aucun cas un feedback suffisant pour trouver la bonne voie.
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
"Je cherche comment implémenter efficacement de l'analyse de fuite[1] afin de pouvoir optimiser les programmes sans que le programmeur doive choisir où allouer ses classes et tout gérer à la main (cf. C++)"
C'est n'est pas encore fini mais l'idée est de garder un GC en library et d'utiliser de la réflexivité.
, je cherche une solution permettant d'avoir des classes et des fonctions génériques sans avoir un surpoids significatif des binaires (cf. C++) sans pour autant sacrifier la performance (en permettant la spécialisation de types/fonctions génériques à l'exécution).
Si tu spécifies à l'exécution tu tombes dans le cas des compilateurs just in time. Cela peut être très puissant pour des codes répétitifs qui sont simplifiables, un peu comme si on finissait une constante propagation, une partie des constantes étant la configuration du logiciel. Par contre, un JIT est loin d'être léger.
Je cherche, comme tous les langages contemporains, une solution simple et puissante au problème de la concurrence.
Lisaac propose COP mais cela n'est pas encore complètement mature.
Est-ce que tu pourrait nous dire pourquoi tu as essayé de créer ton propre langage au lieu de te créer le tien ?
Contrairement aux autres commentaires, je trouve qu'il est très complexe d'attirer quelques personnes de plus qui connaissent bien les compilateurs pour faire avancer un projet qui n'est pas le leur.
"La première sécurité est la liberté"
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par lasher . Évalué à 4.
Je suis tout à fait d'accord. Le domaine de la compilation est l'un des domaines les plus complexes de l'informatique, entre autres parce qu'il mélange aspects très théoriques (théorie des langage, sûreté des types, transformations de programme, etc.) et très pratiques (génération de code).
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Je trouvais dingue de parler de Cduce à une autre équipe Inria, que les équipes qui font des compilos ne se connaissent pas forcément.
Y'a personne à l'inria, pour faire une messe annuelle "compilation", au sens large uniquement pour que les équipes présentes leur travaux ?
"La première sécurité est la liberté"
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par lasher . Évalué à 5.
Maintenant, je veux bien qu'un mec de l'INRIA réponde s'il connaît la réponse (j'en fais pas partie, donc je sais pas...).
Pour ce qui est de CDuce, autant j'aime beaucoup les concepts qui se trouvent derrière (sous-typage sémantique, tout ça), autant la syntaxe est franchement imbitable à mon sens. Je pense que c'est à ce genre de langages que pensent les gens qui parlent de « langages faits par et pour des universitaires ».
(Marwan, si tu me lis, me tape pas)
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par lasher . Évalué à 3.
Pour XML, je pense qu'il faut considérer deux choses.
1/ L'équipe qui a réalisé CDuce, c'est celle des bases de données à Orsay. Ça fait un moment que les chercheurs en BDD s'amusent plus avec les bases orientées XML que les classiques BDD relationnelles.
2/ Justement, XML, ce n'est finalement qu'un ensemble d'arbres (ou parfois de graphes) orientés et ordonnés dont chaque noeud représente un type. Ça permet (proof of concept, tout ça) de générer tout un tas de « types intermédiaires » depuis CDuce, chose qu'il n'est pas possible de faire directement avec OCaml (car il faudrait établir le produit cartésien de tous les types pour pouvoir les faire interagir entre eux).
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Ce qui me gène c'est que l'équipe ne semble pas collaborer avec une autre pour intégrer ce système de typage ailleurs.
"La première sécurité est la liberté"
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
Peut-être parce que ce qui se fait déjà est soit nul, soit largement améliorable ?
Tu sais que ta phrase implique aussi que tu ne vois pas l'intérêt d'XPath, XSLT, XQuery, et bien des choses somme toute très utilisées ?
(Enfin, pour ma part, j'ai du mal à voir l'intérêt d'XML…)
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par auve . Évalué à 6.
Peux-tu expliquer la deuxième partie de cette phrase ? Je ne comprends pas le lien entre inférence de type et une éventuelle absence de sûreté liée à la vérification des types.
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par Amos Wenger . Évalué à 2.
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par Antoine . Évalué à 2.
[^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux
Posté par tyoup . Évalué à 10.
# Langage auto-hébergé
Posté par Philippe F (site web personnel) . Évalué à 1.
J'imagine que tu compile le compilateur ou un sous-ensemble du compilateur avec gcc. Ca veut donc dire que tu maintiens un sous-ensemble du compilateur compilable en C. Ensuite, tu as ton compilateur, et hop, tu recompile la dernière version du compilateur ?
En tout cas, ça veut bien dire que le compilateur principal soit ne peut pas tirer partie des dernières fonctionnalités du langage, soit possède deux modes, un mode ou est il compilable avec une version précédente ou une version de bootstrap, et un mode ou il se compile lui-même ?
C'est pas contraignant de maintenir ce double-mode ?
[^] # Re: Langage auto-hébergé
Posté par Ontologia (site web personnel) . Évalué à 2.
Parce le (2) est compilé avec un compilateur compilé d'un version précédente, donc tu n'es pas indépendant :-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Langage auto-hébergé
Posté par Amos Wenger . Évalué à 3.
En l'occurence, rock est distribué au format source C que lui-même a produit. Quand un utilisateur l'installe, il fait appel au Makefile qui compile les sources C avec gcc, ce qui produit un premier binaire rock, qui est utilisé pour recompiler à partir des sources ooc (assez similaire à ce que tu décris, mais avec une petite nuance quand même).
# While.... mais pas de Do.... While
Posté par FRaph_38 . Évalué à 1.
Do .... While....
Comment fait-on pour contourner ce problème ?
[^] # Re: While.... mais pas de Do.... While
Posté par Philippe F (site web personnel) . Évalué à 2.
--> []
[^] # Re: While.... mais pas de Do.... While
Posté par Amos Wenger . Évalué à 2.
(bonne remarque, en passant)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: While.... mais pas de Do.... While
Posté par Amos Wenger . Évalué à 2.
map each(|key, value|// blah
}
au lieu de:
map each(func (key: KeyType, value: ValueType) {// blah
}}
[^] # Re: While.... mais pas de Do.... While
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il n'utilise que l'opérateur "->" pour redéfinir un arbre. L'idée est de pouvoir réimplanter tous les paradigmes avec le même langage.
"La première sécurité est la liberté"
[^] # Re: While.... mais pas de Do.... While
Posté par Victor . Évalué à 2.
http://www.scala-lang.org/node/138
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.