mais pas tout de suite, c'est mon dernier we avant une semaine d'examens

G_naoj : oui. Je ne suis pas aussi doué que godrik hélas.

caelacanthe : on dit 10.04, pas 10.4 (le 04 signifiant Avril).

hehe. Je suis assez occupe en ce moment. donc si les actions de moderation ne sont pas urgente, j'ai tendance a les traiter par batch.

"caelacanthe : on dit 10.04, pas 10.4 (le 04 signifiant Avril). "

ah, c'était donc ça? je me demandais toujours comment ils faisaient leurs numéros de versions (vu qu'il semblait en manquer pas mal )

Ils publient une nouvelle version tous les 6 mois en avril et en octobre, donc elles finissent toutes par .04 ou .10

Hey les barbus ! Vous pensez quoi du langage Vala ?
Je sens venir les "yet another foo", essayons de défendre un petit peu le bousin.

Vala, c'est un langage qui se base sur le système de types de la Glib : GObject. C'est une solution portable couramment employée pour faire de l'orienté objet en C, a la base notamment de Gtk+ mais aussi la dépendance d'une trouzaine d'autres projets (pas forcément gtk : mplayer, irssi, vlc, rxvt,...).
Vala c'est un langage moderne, a la syntaxe inspirée de C#/Java, qui intègre les fonctionnalités de GObject dans sa syntaxe, épargnant ainsi au programmeur la tâche cruelle de lire et écrire du GObject en C.
Vala, c'est aussi un langage compilé, utilisant comme langage intermédiaire... C (avec GObject) ! Il permet donc de créer de petits exécutables affranchis des énormes dépendances que sont les machines virtuelles C# (mono/.net), Java, python, ruby, etc. C reste aussi le mètre étalon pour la création d'API tant au niveau performance que pour la portabilité vers d'autres langages et vers d'autres plates-formes.
Vala, c'est un langage ayant un compilateur plutôt extensible, qui supporte d'ailleurs une autre syntaxe : Genie, inspirée de Python/Boo/Delphi, pour les amateurs de code élégants avec de l'indentation et sans une tétrachiée d'accolades de merde. Les api résultantes étant nativement utilisables en Vala, en Genie et en C.

Vala c'est un langage assez jeune, développé pour être un remplaçant correct de C pour les applications du projet Gnome (où les développeurs sont notoirement des C++haters), mais qui pourrait à mon avis avoir une portée plus grande.

Yet another language peut-être, mais s'il n'y a pas de feature particulièrement originale dans Vala, c'est l'ensemble de ses aspects -faisant du langage une sorte de C plus agréable à écrire- qui le rendent intéressant à mon avis.

Et vous, qu'en pensez-vous ?

Un lien vers vala : http://live.gnome.org/Vala

pour avoir ecrit du code GTK en C (en fait en C++, mais sans la couche C++ de GTK), je ne peux qu'acclamer un effort (n'importe lequel) de simplification du bousin.

Vala vient avec des choses assez cool pour une "surcouche de C" comme l'encodage des caracteres en UTF8.

Apres est ce qu'un nouveau langage est la bonne solution ? je ne sais pas. Je n'ai pas eu le temps de lire la documentation donc mes questions sont peut etre naive:
-est ce que l'on conserve la compatibilite binaire avec des libs ecrite en C ? (probablement que oui)

Si j'avais besoin d'ecrire une programme pour GTK qui ne sortirait jamais de GTK, probablement que je considererais Vala. Cependant, j'ecris souvent des programmes que je vais porter vers d'autre architectures et ne veut pas me trainer GTK derriere moi.

«-est ce que l'on conserve la compatibilite binaire avec des libs ecrite en C ?»

Oui, compatibilité binaire avec les libs C, pas de binding runtime.
Je n'ai pas encore regardé en profondeur de ce coté, mais l'accès aux libs C depuis Vala (et aux libs Vala depuis C ![1]) est le fondement même du langage : un fichier vapi décrit le binding C-Vala, Vala traduit en C/GObject et GCC compile (ou whatever C compiler works, il y a une option -cc pour définir le backend de compilation C).
Ça se fait donc sans faire un langage frankenstein a la C++, sans surcouche au runtime.

[1]Vala devrait être officiellement ABI-stable a partir de sa version 1.0, et d'ici là il est peu probable que l'ABI change énormément d'ici là. http://www.mail-archive.com/vala-list@gnome.org/msg00532.html

Il y a d'ailleurs un certain nombre de bindings présents sur la page que tu donnes.

Aussi, Vala est seulement lié à GLib, et je pense qu'il peut avoir bien plus de portée que les applis GTK. Je ne sais pas à quel point il est pertinent d'avoir une dépendance sur GLib dans l'embarqué mais ça me parait être une utilisation raisonnable.

Et puis quand on a fini un truc long ou dur on dit :
"Vala, c'est fait"

Je préfère m'auto-censuré que de donner mon avis sur vala. Pour ceux qui me connaissent un peu, ça en dira long.

Moi je te connais un peu, mais avec Ubuntu
Pas en programmation.

• Chris_27 : "Je préfère m'auto-censuré que de donner mon avis sur vala. Pour ceux qui me connaissent un peu, ça en dira long. "

• G_naoj : Moi je te connais un peu, mais avec Ubuntu Pas en programmation."

Chris sur un langage de programmation (mais là il était soft) :
https://www.jeuxvideo.com/forums/1-47-46002-1-0-1-0-go-le-langage-systeme-selon-google.htm#message_46024

Bon, j'attendrais d'avoir regarder précisément la sémantique des objets avant de me prononcer. Même si l'idée est bonne, je ne suis pas sûr qu'on puisse plaquer une couche objet sur du C et conserver ce qui fait de ce langage un bon langage, à savoir sa simplicité.

je viens de tester, pendant une demi-heure, la version live-cd de Lynx Lucide! (envie de jouer à Passage)

par rapport à koala karmique, y a des plus, et des moins

l'ergonomie est toujours acceptable, j'étais sous gnome

là, mon lecteur de disquette a été détecté (enfin ), j'ai enregistré un fichier texte édité avec gedit dessus (j'étais en root, sinon j'avais pas les droits, et il n'a pas réecrit sur le fichier qui existait déja et que j'avais ouvert, mais il a crée un .goutputstream a coté )

et l'utilitaire de disques durs fourni de base a progressé, y a même des benchmarks de performances.

par contre, ils ont moins de logiciels fournis de base (version sur CD), et surtout, surtout, ils ont bien déconné pour le menu de démarrage: sous 9.10, on avait ce menu qui apparaissait tout de suite, avec un tas d'options comme essayer ubuntu sans altérer la machine, installer ubuntu, faire un memtest, tester le cd et booter sur le premier disque dur; après seulement, on attendait trois heures que le système se charge.

Avec 10.04, on patiente d'abord, on arrive sur le menu ensuite, avec deux boutons: essayer ubuntu et installer ubuntu

et ils fournissent moins de logiciels de base. entre autre, il n'y a pas le gimp.

bref, il y a des plus et des moins, ça dépend des besoins de l'utilisateur, après

(ah, et elle ne dérègle pas mon horloge! quand je faisais une session live de karmik koala, mon horloge reculait de deux heures, une heure l'hiver )

On nous parlait de vala il y a peu de temps. Voila qu'un IDE pour vala vient d'etre mis a jour:

http://linuxfr.org/2010/05/18/26870.html

C'est intéressant de voir comme ils ont pompé les bonnes idées de C# (properties, exceptions, delegates).
Mais malheureusement ça me semble pas égaler D encore, et comme ce dernier ça souffre d'impopularité.

Pourtant je trouve qu'on a désespérément besoin d'un langage compilé à haute productivité.

_skip : tu entends quoi par « à haute productivité. » ?

_garfield : j'hésite à te répondre. Si je le fais vraiment, ça risque de partir en hors sujet assez méchamment. Je dirais juste que l'idée de virer Gimp des softs par défaut était une excellente idée (c'est si rare que je pense ça d'une idée issue d'ubuntu que je me sens obligé de le dire).

"Je dirais juste que l'idée de virer Gimp des softs par défaut était une excellente idée (c'est si rare que je pense ça d'une idée issue d'ubuntu que je me sens obligé de le dire)."

okay mais il reste pas énormément de softs orientés dessin fournis de base sur le cd. OODraw?

je ne sais pas ce qu'ils ont mis, à la place, mais de base le nombre de logiciels fournis a diminué

_garfield est mon compte secondaire, exprime-toi

1. Ignorer Chris_27 Chris_27 Voir le profil de Chris_27
2. Posté le 19 mai 2010 à 20:29:47 Avertir un administrateur
3. _skip : tu entends quoi par « à haute productivité. » ?

=> Tout ce qui fait que les temps de développement sont courts et que les grandes bases de code sont facilement maintenables. Actuellement la productivité des langages managés comme java et C# enterre complètement le C et le C++ sur les grosses applications et ce n'est pas qu'une question de frameworks à disposition.

Parmi d'autres :

Code plus concis, déclarations moins redondantes, moins de syntaxes à la con qui compilent sans fonctionner, garbage collector, uniformité des librairies et API, moins de temps de compilation, simplicité de débuggage et d'audit, exceptions généralisées, IDE puissants en refactoring, simplicité des systèmes de tests unitaires etc...

"Pourtant je trouve qu'on a désespérément besoin d'un langage compilé à haute productivité. "

Pourquoi ? Est-ce que des langages comme C# ne te vont pas ? On ne perds quasiment pas de performance avec le JIT compiling (il y a même des papiers qui vont dans le sens d'un possible gain de performance (je ne dit pas pour .NET, mais pour du JIT compiling en général) grâce à des possibilité d'optimisation inconnue à "compile time"). Et ces perfs sont largement compensé par les facilité de manipulation des programme, des dll, etc.

Y'a qu'a voir OCaml, dont on sait tout le bien que j'en pense, mais dont la compilation est assez fastidieuse à gérer.

Il n'y a théoriquement pas d'incompatibilité à avoir les facilité d'un langage managé avec un programme compilé, mais, en pratique, on ne le voit jamais.

D'ailleurs, rien ne t'interdit de précompiler les programme .NET si tu veux améliorer un peu le temps de chargement (mais il faut toujours démarrer le framework).
Et là tu as un langage à haute productivité, compilé. Si tu considère que le framework est déjà de trop, dis toi que c'est précisémment lui, avec les bibliothèques et le GC qui font de C# (ou autre) des langage à haute productivité, et que c'est le cas de tout langage de ce type.

Donc je ne vois pas trop ce que tu cherche comme genre de langage (ou ce que tu reproche à C# et Cie).