Amos Wenger a écrit 91 commentaires

...le pilote libre nouveau!

Mais tellement pratique, avec le basculement automatique sur la sortie HDMI au branchement de l'écran, la sortie de veille bien 4x plus rapide qu'avec les pilotes propriétaires nvidia, les permutations rapides entre les terminaux, les jolies transition... non vraiment ça promet :)

Au niveau de la syntaxe - on est en train d'implémenter ça:

map each(|key, value|
// blah
}

au lieu de:

map each(func (key: KeyType, value: ValueType) {
// blah
}}

Tout à fait. C'est pour ça que j'ai des discussions avec d'autres concepteurs de langage (le concepteur de Vala, d'Io, etc.) - Je me réjouis de discuter avec Martin Odersky (Scala) l'année prochaine, etc.

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.

Pour les feature request, c'est par ici: [http://github.com/nddrylliog/rock/issues]

(bonne remarque, en passant)

« Jusqu'à présent, tu disais plein de trucs intéressants, qui faisaient que je pertinentais à tout va, et puis là, boum, catastrophe »

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]

@bluestorm: Merci pour l'explication, je comprend mieux ton point de vue. J'ai censuré le tutoriel (il y a le bon et le mauvais contributeur..). La page d'accueil est trop longue, on va la refaire en se basant plutôt sur un modèle à la http://rubini.us/
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.

J'ai effectivement tendance à prendre trop à coeur ce genre de critiques - mais je jure sur la tête de Bjarn que j'écoute et je prend en compte.

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)

Si on veut. A cela prêt que pour les langages source-à-source (ooc, Vala, etc.) on peut conserver la version source du compilateur (2) et donc être vraiment indépendant du (1) à partir d'un certain moment.

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).

D'autres réflexions:

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..

Courage, la molette est toujours utile de nos jours:

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..)

Ah, et au passage: oui, nos closures sont des vraies closures. Qui capturent le contexte. Pas juste des fonctions anonymes.

Ma foi, je n'ai pas le temps de répondre à tout, mais voici quelque points:

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.

En effet, la cross-compilation est souvent un vrai défi =)

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

Mais c'est une véritable interview! J'aurais dû prendre ma cravate ;)

- 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!

Merci! On vous tiendra au courant à la prochaine version majeure =) (Autant dire qu'il y a du pain sur la planche)

Non ce n'est pas encore vraiment ça =)

'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.

http://docs.ooc-lang.org/language/libs.html

Non =)

_{} et ";"

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 = 42
et qu'on enlève le type, on obtient
i := 42
Voilà 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.

ben oui =) ça marche pareil en ooc

for(file in listFiles) {
file read() println()
}


'listFiles' peut-être n'importe quelle classe qui implémente Iterable, bien sûr.

Est-il facile d'utiliser une bibliothèque écrite en C? En C++?

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).

Juste pour signaler que pour l'occase, un canal IRC en français a été créé sur Freenode, n'hésitez pas y passer si vous avez des questions en particulier: #ooc-lang.fr

Hello there,

>> 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 =)

Comment, on est pas le premier avril?

Ils ont bien breveté le double-clic...

Le nom me disait vaguement quelque-chose, je viens d'aller voir sur Wikipédia, ce projet me semble intéressant aussi =) Dans ses différences avec ooc, Lissac = orienté prototype et héritage Smalltalk/Eiffel, ooc = orienté classe et héritage Java/C#, etc.

Si tu dois passer une semaine à te rendre compte par l'échec de ton appli que le GC que tu utilises n'est pas parallèle, eh bien... RTFM.