Discussion :

[smyley]

Au fait, juste un truc ... le but ultime c'est de redévelopper un système comparable aux ActiveX d'IE ?

[deadalnix]

A mon avis, le but c'est d'envoyer du code à travers le navigateur.

Code qui doit compiler vite sur toutes les platesformes. Si le code utiliser une lib standard, il est possible d'en restreindre les possibilités afin de ne pas se retrouver avec des activeX 2.0 .

[smyley]

Donc Google réinvente le javascript/JITed ?

[deadalnix]

Oui, mais compilé en natif.

Et c'est censé multihreader de base, même les benchs montrent que ça marche pas terrible. En tous cas, bien moins bien que python.

Et ils ont l'air de vouloir réinventer le D en même temps.

[smyley]

Oui, mais compilé en natif.

Ben avec V8 on a bien un javascript compilé en natif. Le pire, c'est que V8 est aussi développé par Google ... ça doit les amuser de recoder leur propre code

[deadalnix]

Sauf que javascript, c'est quand même limité dans les possibilités.

Et aussi qu'il n'ont pas de possibilité d'évolution du langage. Pour cela il faut passer par l'ECMA, ça prend des lustres et au final on change presque rien parce personne n'est d'accord.

Avec Go, ils ont la main sur la techno et peuvent la faire évoluer comme bon leur semble.

[smyley]

Mais justement le truc c'est qu'actuellement, pour chaque couple "natif/compilé" ou "web/pas web" il existe déjà un langage avec tout un écosystème derrière.
Si on cherche du web il y a du php/javascript/etc et pas web on trouve toute la série des C et aussi Java et compagnie.
Là on a un n-ième langage spécialisé, mais encore plus minimaliste que bon nombre de ses concurrents (ça me fait penser un peux au KPL, en plus compliqué ...)

[piklein]

Il ne faut pas se leurrer : l'objectif de google en lançant un nouveau langage de programmation est de contrôler, s'approprier, distribuer, faire partager du code dans un langage dont google serait propriétaire.
Le débat n'est donc pas tellement de savoir si le langage apporte des améliorations par rapport à d'autres langages, mais plutôt de comprendre les finalités visées par Google.
Google développe des applications basées sur le "cloud", et leur business est de collecter du contenu de n'importe quelle nature (photo, vidéo, données sociales, contenu web, musique, livres électroniques etc...) afin de pouvoir en tirer du profit.
Maintenant c'est le code source de millions de bénévoles qui va être utilisé à des fins commerciales, avec l'aval des contributeurs, et pour la plus grande richesse d'actionnaires en tous genres.

[GanYoshi]

Maintenant, comparé à D, Go est volontairement minimaliste :
- Pas d'exceptions
- Pas de RAII.
- Pas d'héritage (que des interfaces)
- Pas de surcharge de fonctions ni d'opérateurs.
- Pas de possibilité d'être appelé depuis du code C (seul l'inverse est possible).
- Pas de templates.
- Pas de possibilité de gestion manuelle de la mémoire.

Je vois pas en quoi le fait d'avoir moins de possibilités peut constituer un avantage...
Par exemple l'absence de surcharge de fonction, quand elle existe elle dérange personne, et lorsqu'elle n'existe pas ça peut vraiment être gênant.
Pareil pour l'héritage, pareil pour les exceptions, pareil l'impossibilité d'appeler du code C, pareil pour tout en fait.

Certes mais comme Microsoft et le seul maitre a bord de l'évolution de .NET, mono est condamné a rester une technologie qui suis de loin .NET, un peu comme l'est wine.

C'est clair que c'est pas sérieux...

Sinon +1 piklein rien à redire ^-^

[deadalnix]

Je vois pas en quoi le fait d'avoir moins de possibilités peut constituer un avantage...

C'est aussi le paris qui à été fait par java. Et à la vue de ta signature tu y as trouvé un intérêt.

Perso je n'en ai en effet pas trouvé, mais force est de constater que ça marche dans la pratique C'est pourquoi j'aime C++ et encore plus D. Ou bien quand on n'a pas besoin de tant de rigueur, je préfère carrément m'orienter vers des choses type python.

smyley > On est d'accord, il existe déjà des langage remplissant ces rôles. J'expliquais quelle était l'intérêt de google dans l'affaire, mais je ne suis moi même pas convaincu par ce langage.

[Niark13]

Je vois pas en quoi le fait d'avoir moins de possibilités peut constituer un avantage...
Par exemple l'absence de surcharge de fonction, quand elle existe elle dérange personne, et lorsqu'elle n'existe pas ça peut vraiment être gênant.
Pareil pour l'héritage, pareil pour les exceptions, pareil l'impossibilité d'appeler du code C, pareil pour tout en fait.

Par exemple, un langage qui n'a pas d'exceptions, ça permet de voir tous les flux d'instructions possibles rien qu'en lisant les sources. Y a pas de saut caché au premier catch qui correspond. Par contre, je suis d'accord, c'est beaucoup plus chiant à écrire.

L'asbence de surcharge de fonction peut éviter que la mauvaise fonction soit appellée si on oublie de caster (en cas de conversion implicites). Exemple en Java :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
void f(int i) {
    //...
}
 
void f(short s) {
    //...
}
 
void g() {
    short a = 2;
    short b = 3;
    f(a + b); // Appelle f(int) (conversion implicite vers int)
    f((short)(a+b)); // Appelle f(short)
}

Sans pour autant apprécier ce manque de fonctionnalités, je peux comprendre quel est le raisonnement qui a pu aboutir à ce choix. Il s'agit d'éviter de faire perdre du temps sur un bug à la con à un développeur débutant. Et le temps, pour une boîte, c'est de l'argent...

Gosling avait dit qu'il avait eu la même démarche en concevant Java : tout ce qu'il ne jugeait pas indispensable avait été retiré. Je cherche pas à glorifier Go (en fait j'en ai un peu rien à f..., contrairement à D que j'apprécie beaucoup), mais il faut pas croire que le manque de features n'est pas mûrement réfléchi.

Par contre, tu as du mal lire mon précédent post (ou alors je me suis mal exprimé). Go est capable d'appeler du code C (heureusement). Par contre, il est impossible d'appeller du code Go depuis du code C. C'est clairement un problème selon moi.

[smyley]

Le retrait de fonctionnalités pour diminuer le nombre d'erreurs possibles n'est pas vraiment captivant comme argument ...

[deadalnix]

Quand on le fait pour les pointeurs, tout le monde crie au génie.

Quand on le fait pour la surcharge d'opérateurs, tout le monde crie au génie.

Mais quand on le fait pour d'autres truc, c'est pas bien ?

[tomlev]

Quand on le fait pour les pointeurs, tout le monde crie au génie.

L'intérêt n'est pas de supprimer la possibilité de manipuler des pointeurs, mais de supprimer le besoin de manipuler les pointeurs ! D'ailleurs, si on prend C# par exemple, il reste possible de manipuler des pointeurs dans un contexte unsafe, bien que ce soit rarement nécessaire.

Quand on le fait pour la surcharge d'opérateurs, tout le monde crie au génie.

Ah ? pas moi en tous cas...

[smyley]

il reste possible de manipuler des pointeurs dans un contexte unsafe, bien que ce soit rarement nécessaire.

On peux même rester dans le contexte safe en se battant avec la classe IntPtr et la classe Marshal, qui permet de faire de faire pas mal de choses.

De plus, la surcharge d'operateur est vraiment quelque chose de formidable, tout comme l'héritage, la surcharge de fonctions, les generics, etc etc.

[ash.ice.loky]

Quand on le fait pour les pointeurs, tout le monde crie au génie.

Quand on le fait pour la surcharge d'opérateurs, tout le monde crie au génie.

Mais quand on le fait pour d'autres truc, c'est pas bien ?

on parle toujour de développement car la j'ai un doute !!

il ne faut pas confondre simplification et suppression de possibilités.

[deadalnix]

Bien, dans quel langage peut-on faire de la méta-programmation ?

Bien sur que si qu'il y a des fonctionnalités enlevées a tour de bras dans les langages modernes.

[Alp]

Il parle de quelle sécurité ? contre la décompilation ?
Parce que je ne vois pas d'autre 'avantage' question sécurité d'un code compilé.

La typesafety, bien qu'en C ça soit nettement moins vrai.

[Tommy31]

Bien, dans quel langage peut-on faire de la méta-programmation ?

Java, Python, Ruby, Groovy...

Bien sur que si qu'il y a des fonctionnalités enlevées a tour de bras dans les langages modernes.

C'est plus les "idiomes" qui sont évincés que des fonctionnalités, ou des éléments paradigmiques.

[Niark13]

Le retrait de fonctionnalités pour diminuer le nombre d'erreurs possibles n'est pas vraiment captivant comme argument ...

Google a viré tout ce qu'ils interdisent à leurs développeurs pour leurs projets. Si tu fais du code chez Google, tu dois pas surcharger des fonctions. J'ai cité des raisons qui les ont poussé à choisir ces guidelines, ça ne veut pas dire que je sois fondamentalement d'accord avec celles-ci, hein.

De plus, la surcharge d'operateur est vraiment quelque chose de formidable, tout comme l'héritage, la surcharge de fonctions, les generics, etc etc.

La surcharge d'opérateur, ça dépend comment c'est fait. Employé à l'excès, ça peut nuire à la lisibilité du code.
L'héritage, c'est pareil, ça doit être employé quand ça se justifie et pas seulement pour économiser quelques lignes (cf. Liskov). Erreur que la plupart des débutants font car ils n'ont pas le recul nécessaire pour l'apprécier.

Go donne l'impression d'un langage conçu par des managers.