Par exemple, c'est quoi le  binding, STP ?

To bind = Relier. C’est assez proche de To link = Connecter/Lier, mais différent. En même temps, les deux mots ne sont pas étrangers l’un à l’autre.

Un phrase pas très claire mais qui donne une idée : on utilise un bind quand on ne peut pas faire un link directement.

Quand un ensemble de choses hétéroclites doivent être intégrées ensemble et qu’elles ne peuvent pas communiquer directement entre elles pour des raisons techniques, alors on peut tenter de faire un binding entre les deux. Si elles ne se branchent pas naturellement l’une à l’autre, on va coller quelque chose sur l’une des deux, une chose à travers laquelle on va pouvoir les brancher.

Par exemple, GTK est en C. Pour une application en C, il n’y a rien à faire de trop spécial pour lui permettre de se lier à GTK. Mais depuis n’importe quoi d’autre, se lier à GTK ne pourra pas se faire directement. Par exemple PyGTK, la librairie Python pour utiliser GTK, utilise un binding pour permettre à Python de se lier à GTK.

Un binding, c’est un intermédiaire, un adaptateur (comme pour les prises et branchements).

En C, on pourrait dire qu’on a : GTK ⇔ programme C.
En Python on pourrait qu’on a : GTK ⇔ Binding GTK‑Python ⇔ Python

Le binding est une technique tellement courante et nécessaire en pratique, que beaucoup de langages fournissent un support intégré pour aider la création de bindings. C’est le cas de Eiffel, Ada, Python, par exemple, mais pas de SML, JavaScript, ni même le C d’ailleurs (c’est les autres qui font le travail pour lui, lol), par exemple.

Et le plus souvent en pratique, les bindings se font depuis depuis un langage qui n’est pas le C, vers quelque chose qui a été fait pour le C. Le support pour les bindings, fourni par Python, ne concerne d’ailleurs que le C. Mais ça n’est pas toujours le cas, et Ada par exemple fourni un support pour les bindings vers C, Cobol et Fortran (et C++ pour le compilateur Ada de AdaCore). Eiffel aussi est comparable à Ada sur ce point (directive external qui prend le nom du langage, … mais il doit être supporté).

Cependant, n’importe quel langage peut être utilisé, dès qu’un binding avec les librairies requises est disponible (au besoin, ce binding peut être créé).

Super intéressant, toutes vos réponses, surtout celles du début du topic qui sont assez compréhensibles même pour quelqu'un comme moi qui débute en programmation (seulement une peu de python et de javascript pour l'instant). Après, c'est un peu pointu pour moi.
Cependant, dès le début, il y a des choses que je n'ai pas comprises. Par exemple, c'est quoi le  binding, STP ?

Personnellement, je trouve que la curiosité n'est pas un vilain défaut et que connaître le système qu'on utilise est plutôt bien, même si ça ne sert pas dans l'absolu. La culture informatique n'a pas toujours à être utilitaire, non ?

Vala est typé (+ inférence de type), avec contrôle statique, avec une forme modularité, sans closure, il compile vers le C […]

Par contre là j’ai dit une bêtise. Je viens d’apprendre qu’il a des vraies fermetures, presque comme dans les langages fonctionnels (*), avec les fonctions anonymes.

(*) Je dis « presque », parce qu’avec les effets de bords, il n’y a une fermeture que pour les références, pas pour les valeurs.

Sinon, une liste des applications en Vala. On y retrouve plusieurs composants d’Ubuntu :
Vala Documentation — Projects Developed in Vala (live.gnome.org)

Concrètement, les nouvelles applications GNOME seront en javascript, à l'instar de GNOME Document. Les autres ne devraient pas migrer sauf avis du mainteneur. Ainsi GNOME Contact restera en Vala.

Je crois que tu interprète mal

JavaScript est non‑typé, sans contrôle statique, sans modularité, avec closure, interprété, pas conçus pour créer des applications toute entière, mais convient bien pour les petites, sauf quand on fait des grosses choses avec parce qu’il n’y a pas le choix (ex sur le web). Vala est typé (+ inférence de type), avec contrôle statique, avec une forme modularité, sans closure, il compile vers le C, un langage natif, et même si je ne le recommanderais pas pour des applications à grandes échelles, il se défendrait bien dans ce domaine, mais en tous les cas, pour les interface utilisateurs, son modèles sous‑jacent convient bien, et même mieux que celui de langage plus stricte pour forcément commode pour les interface utilisateurs.

Si cette personne a abandonné Vala, c’est sûrement qu’elle est partie vers des horizons où Vala ne convient pas. Elle a aussi peut‑être été impliquée dans Vala pour certaines raisons, et a simplement décidé de passer à autre chose.

C’est plutôt normal que Vala soit un favori pour Unity, car en plus d’avoir les caractéristiques données plus haut, il est entièrement orienté vers GObjet, et il a même été créé pour ça, pour être un langage adapté à GObjet, sans avoir à passer pour toutes les lourdeurs d’écriture que le C impose à GObject depuis le C.

Vala pour Ubuntu, c’est comme Objective‑C pour Mac ou Visual Basic pour Windows.

Bref, tout ca pour dire que oui, unity est codé en vala (comme je l'imaginais), et oui, unity sucks (comme les trolls le crient depuis 3ans)

Ca se confirme

C'est très décevant de la part de ce projet .. une fois de plus.

Je ne sais pas si Unity est en Vala, […]

Shotwell est en Vala, ça c’est sûr.

unity c'est du vala

Ah si, il y a quand‑même eu une référence à Vala dans ce sujet. Je croyais qu’il avait été oublié.

Alors je serai passé pour re‑citer.

Je ne sais pas si Unity est en Vala, mais j’ai l’impression suite à des lectures sur le Net, que Canonical met beaucoup Vala en avant depuis Unity. Peut‑être que Vala va être à Ubuntu/Canonical, ce que Objective‑C est à Mac OS/Apple.

Voilà, c’était pour souligner Vala, qui n’avait été mentionné qu’une seule fois dans ce sujet.

Ben je ne comprend plus rien, je répond à un message en le citant, et le message que je citais à disparu ? Où c’est moi qui m’emmêle les pinceaux ?

Tu cites mon message du post #24.

Et je ne l'ai pas supprimé, il est toujours présent.