[F] [mOved] Mon langage est mieux que le tien - Page 8

Nouveauté d'aujourd'hui dans les repos de Debian testing : http://kayalang.org/ ça, c'est vrai

Apparemment, ça enterre Swift, et de loin ! ça, j'en sais rien


</troll >


Ceci dit, l'inférence de type a évidemment fait tilté mon oeil au premier abord (même pas besoin de déclaration pour les vars locales dont le type peut être inféré )
Après, c'est un langage compilé , mais j'en sais pas beaucoup plus. Ca a juste l'air pas si mal que ça au premier abord.
Je vois aussi des bindingspour SQL, SDL, ncurse, GD et OpenGL. Vu la manière dont les paquets sont ajoutés à Debian testing, ça ne devrait être qu'un début.

Ca a l'air plutôt sympa ouais, et ça a l'air d'être un peu la même famille de langages. Remarque ça devrait venir de plus en plus dans le futur ça, parce qu'aujourd'hui on saurait faire un "C++ simplifié" qui ait tous les avantages de ce dernier, voire plus.

Heu j'ai regardé le site, et franchement la syntaxe à l'air totalement incompréhensible et pas du tout cohérente. C'est peut-être juste leurs exemples qui sont gerbants (à l'image de leur site...) mais honnêtement, du peu que j'en ai vu, je pense que je préfère largement le JavaScript, même si à l'heure actuelle c'est moins puissant et pas vraiment compilé.
En tout cas je coderais jamais avec une merde pareille

(Et pourquoi je parle de JavaScript ? Bah ce langage, on dirait du JavaScript qui se serait fait violer par du OCaml, du C++, du C# et du Java...)

Je ne saurais répndre ni à l'un ni à l'autre. Mes connaissances se limitent au 68k, et un peu au C et au C++. Pas plus (plus ). Je vous laisse vous étriper, c'est le côté similaire au swift qui m'a fait vous proposer ce lien.

Je confirme GoldenCrystal. Niveau fonctionnalité ca ressemble a Rust ou a Swift : un langage avec une syntaxe à la C qui emprunte des fonctionnalités tirées de langages fonctionnels. Je dirais que le créneau commence a être saturé en ce moment.

-

L'assembleur est--il un langage ?

Tu te sens l'âme d'un philosophe, aujourd'hui ?

" BCC or BCS that is the question " -- let C a(s)m

Complètement. Je pourrais disserter longuement sur la philosophie de l'assembleur, qui est à la programmation ce que l'action est à l'homme.
Pensée -> action
Langage de haut niveau (concepts + implémentation + compilation) -> assembleur (exécution pure)
Je peux développer pour ceux qui ont du mal à suivre les hautes sphères programmaticalliticiennes.

(exg ./219, ./220)

Ça fait quand même un paquet de langages qui sortent ces derniers temps, je ne sais pas si c'est murement réfléchi mais j'ai du mal à croire qu'on ait tout à coup besoin de 15 nouveaux différents. Comme si tout le monde s'engouffrait dans une brèche pour avoir une chance d'être le nouveau langage à la mode de 2014, mais j'espère bien qu'au final il vont quasiment tous mourir sauf un ou deux parce que pour l'instant ils se ressemblent vraiment tous.

C'est clairement ça

Tout le monde a le même besoin d'un langage efficace mais moderne, et chacun essaie d'amener sa solution. Après, je ne sais pas si Mozilla a suffisamment de poids pour faire adopter massivement un langage rapidement, surtout s'il est un peu complexe (Rust me semble assez complexe avec pas mal de notions à assimiler dès le début, mais je me trompe peut-être, je n'en ai jamais fait).

Depuis une petite dizaine d'années, tout le monde a bien compris que les langages actuels sont insuffisants lorsque l'on cherche à réunir à la fois la productivité, la sécurité et la performance. C'est la raison pour laquelle il y a autant d'initiatives après une longue période de stagnation, et c'est une bonne chose. Cela dit, il y en aura beaucoup qui ne décolleront pas, même si ils sont poussés par les géants du secteur.
À mon avis, Go et Dart (Google), Rust (Mozilla), Ceylon (Red Hat), Hack (Facebook) et bien d'autres ont très peu de chance de sortir de l'anonymat. Pour Swift en revanche c'est un peu différent car il va forcément remplacer l'Objective-C à la place de 3e langage le plus utilisé dans le monde (d'après l'indice TIOBE).

Hack n'a aucune chance, je ne connaissais même pas Ceylon.

Pour Go et Dart, je ne sais pas. Il y a quand même Google derrière, mais je ne sais pas s'ils vont convaincre les gens d'y adhérer.

Pour Swift, c'est clair qu'Apple va convaincre une partie non-négligeable des développeurs pour iOS / OS X. Mais je ne sais pas si ça suffira à déborder de ce cadre.

Ben s'ils font ça aussi mal qu'Objective-C (et ça a l'air parti pour) alors non ça ne décollera pas. Perso un temps j'avais envie de faire de l'Objective-C sur d'autres plate-formes mais en fait ça ne sert juste à rien donc je suis revenu au C++...

Attention le TIOBE n'est certainement pas l'indice des langages les plus utilisés dans le monde, (ce genre de statistique serait bien difficile a réaliser) mais simplement l'indice des nom de langage les plus recherchés dans les moteurs de recherche ce qui est quand même bien différent.

Swift est annoncé comme le successeur de l'ObjectiveC dans les environnements MacOS X/iOS et avec tout le buzz que génère Apple il s'y trouvera certainement très vite en bonne place que le langage soit de qualité ou non.

Mais il y a fortement a parier qu'il restera cantonné a ce domaine

C'est un peu plus compliqué, je crois que ça prend en compte l'activité sur différents forums. Mais il reste difficile de dire ce qu'il signifie réellement.

En tout cas, on voit de grandes tendances : le C reste stable depuis 12 ans, le Java diminue, Objective C a explosé avec l'iPhone, C++ s'est pris une claque en 2004 et baisse depuis 2 ans, PHP baisse depuis 4 ans, Javascript ne décolle pas vraiment malgré toutes les annonces qu'on a vues.

Hmm, JavaScript est clairement un des langages les plus à la mode en ce moment, même si ça ne ressort peut-être pas sur l'indice. (Et puis ça ne concerne pas non plus tous les corps de métier)
Depuis quelques temps déjà, mais encore plus aujourd'hui, la plupart des entreprises migrent vers des applications « client léger » (j'ai toujours trouvé ça assez ridicule d'apeller ça « léger » vu la façon dont c'est généralement utilisé mais bon… ), et aujourd'hui, la mode est aux SPA, donc JavaScript + REST. (Et puis de toutes façons Gartner a dit qu'il fallait faire ça, donc tout le monde le fera)
Le plus intéressant là dedans est que cela n'évince pas du tout les habituels candidats au développement Web en entreprise (PHP, Java, C#), même si ça réduit sensiblement leur part dans les projets. (Et évidemment, pas *tous* les projets)
Bon, après, node.js est très à la mode et devenu incontournable pour un certain nombres de choses dans le domaine du développement Web, en revanche je le vois encore mal sur un serveur web dans les grandes entreprises, mais qui sait…

(Quant à l'indice TIOBE, il me semble qu'il calcule le nombre de résultats par recherche sur certains mots clés, genre XXX + " programming", mais à voir si pour JavaScript ça tient aussi compte de "jQuery" et autres frameworks qui au fond sont purement liés au JavaScript ^^)

(ils appellent ça «client riche» en fait)

+1 sur le fait que JS soit devenu très à la mode, et sur les limites de l'indice TIOBE, même s'il n'est clairement pas inutile.

Les accidents de 2004 sur les courbes TIOBE, où les courbes du C et du C++ ont beaucoup baissé, sont dus à un changement de méthodologie. C/C++ étaient légèrement sur-représentés avant 2004 à cause de certaines optimisations de l'indexation des moteurs de recherche, ils ont essayé d'annuler un peu cet effet.

Ce qui reste complétement idiot car personnellement les langages sur lesquels je fait le plus de recherche ne sont pas ceux que j'utilise le plus bien au contraire.
En général, je fais plutôt des recherches sur un moteur, quand j'ai ponctuellement à faire à un langage que j'utilise peu et/ou qu'il est mal documenté et plein de problèmes contrintuitifs.

j'ai essayé de faire des recherches par langage sur Github, mais il faut fournir au moins un terme à chercher
En cherchant « e », j'ai trouvé
112 résultats en Rust
70 résultats en Swift
1 518 résultats en Go

Accessoirement, j'en trouve 25 532 en Python, 57 273 en Javascript, 46 132 en Java, 28 650 en Ruby, 27 720 en PHP, 15 411 en C, 13 873 en C++ et 11 320 en C# et 7 164 en Objective C.


En cherchant « i », on a respectivement 123 en Rust, 94 en Swift, 1 262 en Go, 23 762 en Python, 60 782 en JS, 34 782 en Java, 25 507 en Ruby, 23 964 en PHP, 12 439 en C, 12 510 en C++, 9 519 en C# et 23 696 en Objective C.

Si vous trouvez des stats plus fiables, je suis preneur ! Je ne sais pas si c'est beaucoup mieux que TIOBE
En attendant, Swift se débrouille pas si mal que ça.

Peut-être en essayant quelque chose comme ça : http://adambard.com/blog/top-github-languages-for-2013-so-far/ ?

Edit: il y a plusieurs sites avec des stats un peu plus variées
http://langpop.corger.nl
http://lang-index.sourceforge.net
http://langpop.com
https://sites.google.com/site/pydatalog/pypl/PyPL-PopularitY-of-Programming-Language

Attendons que le soufflet retombe un peu et que le language devienne "publique"

http://stackoverflow.com/questions/3592557/optimizing-away-a-while1-in-c0x?lq=1
Qui a eu cette idée à la con, sérieux ?!
(et ce n'est pas purement théorique, apparemment il y a plusieurs compilateurs majeurs qui suppriment les boucles infinies vides)

Cette modif du langage est catastrophique pour le code embarqué, ça peut entraîner des dysfonctionnements graves. Rien que pour le code d'un projet sur lequel je suis en ce moment, ça désactiverait des sécurités qui sont là pour empêcher que quelqu'un puisse se blesser ou que le matériel soit détruit

(je passe pour un extrémiste quand je dis qu'aucun code critique ne devrait être écrit en C, mais quand on voit des trucs pareils...)

En C++ tu veux dire ?

La même en C:
http://blog.regehr.org/archives/140

Après analyse, en C, si un compilateur fait une telle transformation, il est buggué. Le C11 est clair :

An iteration statement whose controlling expression is not a constant expression that
performs no input/output operations, does not access volatile objects, and performs no
synchronization or atomic operations in its body, controlling expression, or (in the case of
a for statement) its expression-3, may be assumed by the implementation to
terminate.

Donc while (1) ne peut pas être optimisé en C.
En C++, je ne sais pas.

EDIT: En fait, l'exemple donné ne correspond pas à une optimisation de while (1) mais au fait que la fonction, si elle retourne, ne peut retourner que 1, et donc elle n'est même pas appelée par les compilateurs fautifs !

Pourvue qu'une telle absurdisté n'arrive pas dans le C... Le C, meme si il est en train de perdre cette partie, ce doit d'etre deterministe, si un bout de code change de fonctionnement suite a la bonne volonte "optimisante" du compilateur, ou va le monde? :/

PpHd > la formulation repousse juste le problème sous le tapis. Si le compilateur n'arrive pas à déterminer si une expression est constante ou non, il va supposer qu'elle n'est pas constante, et donc potentiellement supprimer une boucle infinie. Ça ne se produira peut-être pas pour while(1), mais rien ne dit que ça n'arrivera pas dans des cas plus complexes. C'est le raisonnement sous-jacent qui est faux : le compilateur ne devrait supprimer les boucles que s'il est certain qu'elles ne sont pas infinies. Je trouve ça complètement dingue que ceux qui rédigent les spécs soient prêts à casser quelque chose de fondamental dans le langage (et faire foirer des programmes valides) juste parce que ça permet des optimisations plus agressives. Comme disait quelqu'un, on peut faire plein d'optimisations si le résultat n'a pas besoin d'être correct...

Godzil > malheureusement, le C n'a jamais été réellement déterministe (tout comme il n'a jamais été réellement portable), il y a bien trop de choses laissées au choix du compilateur dans les spécs. Certains rétorqueront qu'il suffit d'éviter les constructions qui posent problème, mais il y a tellement de cas que je ne pense pas qu'il existe quelqu'un au monde dont tous les programmes fonctionnent correctement avec tous les compilateurs (et là, je ne parle même pas des bugs des compilos). Même la norme MISRA, qui impose un paquet de trucs, ne permet pas de garantir ça.