[blabla@olympe] Le topic du modo, dieu de la fibre et du monde

 [:papatte]

 :ouch:  [:vapeur_cochonne]

Oui il fait l'autocomplétion en cours de frappe façon eclipse/Visual Studio (avec propositions intelligentes, listage des méthodes de l'objet, affichage des paramètres), et permet d'accéder aux définitions/déclarations à tout moment (bon parfois il a du mal). Par contre il ne va pas vérifier ta syntaxe. Mais c'est déjà vraiment pas mal comme support du langage pour un IDE. Il correspond en tout cas à un environnement de développement que je peux utiliser dans le domaine professionnel.

Aptana a repris RadRails et ils supportent RoR assez bien. Sinon y a Netbeans 6 (RC1) qui supporte très bien Ruby et RoR et pour le moment je préfére à Aptana, exemple tout con, il est capable d'aller voir à l'intérieur de tes models ActiveRecord pour te proposer la completion auto des champs du model (je sais pas s'il se base directement sur la table associée ou sur la migration par contre), ce qu'Aptana ne savait pas faire (mais étant donné que celui ci a du évoluer depuis le temps, je sais pas ce qu'il vaut today).

(j'avais vu ta réponse avant l'edit, mais je suis pas sûr que ton edit soit moins trollesque [:petrus75])
Le problème des dépendances n'est pas nouveau et surtout pas inné à Java ; je sors d'une boîte où j'ai passé ma dernière année à réarchitecturer une appli en réduisant les dépendances de manière drastique. Tout ce beau monde était codé en... C++ [:petrus75]

Oui mais quand ton programme utilise 2 ou 3 libs de logging (un commons-logging-1.0.4, un log4j-1.2.9, un log de la Javalib par ex.), et 2 ou 3 libs d'expressions régulières (un jakarta-oro + un jakarta-regex) comme on le voit régulièrement (souvent pour un seul appel, alors que les regex de la Javalib sont excellents et suffisants dans 99% des cas), je trouve qu'il y a un peu d'abus de framework-ite. Aaah mais tel framework a besoin de cette lib. Peut-être, mais là encore, le choix d'un framework, ça se planifie, et se demander si on a réellement besoin d'embarquer telle ou telle lib n'est vraiment pas du luxe.  Il n'est pas rare de voir une appli web embarquer 20 ou 30 jars, dont 6 ou 7 en doublon avec Tomcat. Le classpath n'en finit pas de grossir et la maintenance des versions devient un casse-tête. A ce moment-là, on peut se demander si le système est réellement maîtrisé. Parfois, ça vaut le coup de dézipper un jar et de récupérer juste la ou les 3 ou 4 classes que l'on utilise vraiment au lieu d'embarquer les 145 autres dont on sait qu'elles ne nous serviront jamais.

Ca me fait penser qu'en regardant la cat C++, j'ai jeté un oeil au forum d'un sympathique nouveau framework multimédia/Jeux vidéo. L'une des questions que l'auteur a posé pour l'évolution du framework est s'il valait mieux multiplier les formats supportés, ou bien réduire les dépendances envers des librairies externes, quitte à sacrifier quelques fonctionnalités ("Is it worth supporting less formats for removing dependencies on external libraries ?" ). La réponse est pour l'instant à 100% oui. Ce serait bien que les programmeurs Java adoptent la même philosophie...

On dirait un dialogue de dragon ball Z [:iansolo]

Mais c'est aussi et surtout du XML [:aloy]  
 
Même la puissance fonctionnelle ne peut rien faire contre la moisissure XML [:totoz]  

[:nul]

XSLT est un langage fonctionnel que ça te plaise ou non :o
Lisp XSLT même combat :o

Il fait l'auto completion ? il disent le contraire dans l'article de wikipedia sur D
Et puis moi j'en attends plus, genre me rappeller les paramètres d'une fonctions, me trouver le code de ladite fonction, m'indiquer les erreurs syntaxique en temps réel, etc .

[:benou_grilled]

[:rofl] ça c'est un test pour doudoule [:dawa]
 

ben C'est ce que le gars dis, c'est mieux de faire des fonctions courtes mais des fois t'as pas le choix. J'ai eu des collègues qui voulaient absolument respecter cette "règle" de la fonction de moins de 30 lignes et qui trichaient pour pas dépasser la limite: ils mettaient 3 ou 4 instructions par lignes ou ils tronçonnaient une fonction trop longue en n fonction sans aucun sens.  

Les frameworks, je connais pas, j'en ai jamais utilisé, mais t'es souvent obligé de multiplier l'usage de libs quand ton programme commence à faire pas mal de choses différentes. Certes tu as déjà pas mal de choses en standard mais tu n'as pas tout :spamafote:

Ben c'est El Awrence :spamafote:

J'avais le même problème quand j'ai commencé RoR mais c'est passé assez vite (~1 semaine je dirais), même si c'est vrai que quand le projet est un peu complexe ca peut prendre un peu de temps de retrouver à quel endroit se trouve une fonction.

[:psywalk]

Y'a pas un plug in aptana pour RoR? D'ailleurs, il me semble que c'est plus qu'un simple plug in car je crois me souvenir qu'ils ont repris le projet RadRails.

Merise FTW :o

[:pingouino]

 
http://www.macguff.fr/goomi/unspea [...] bvious.jpg  

ce topic de merde [:rofl] Du pur blabla de qualitay

Oui, aussi. :jap:

Je viens d'avoir ça aussi mais au deuxième essai c'est passé. :/ Il faut autoriser les cookies aussi.

Edit : pour la cinquième question a[] contient des dwords.

un IDE pour moi ça sert avant tout à naviguer dans le code, c'est une des raisons pour lesquelles j'ai viré RoR : j'avais le source mais je passais ma vie à  faire du grep pour tenter de trouver un truc. Et je m'en sers aussi pour des manipulations de haut niveau du code, jouer avec un AST plutôt qu'avec des chaines de caractère.

Insert into answers failed :/

Y'a du vrai et du moins vrai la-dedans. Par exemple, quand il dit que "sometimes things are most simply expressed in one long function", moi je me méfie. Effectivement, dire qu'une fonction ne doit pas dépasser 20 ou 30 lignes, c'est pipo, mais d'expérience, une fonction qui fait 500 lignes ou manipule 15 variables peut pratiquement toujours être découpée, et le faire est presque toujours bénéfique à la fois pour la compréhension et pour le débogage.

Il a oublié un point: l'usage de N frameworks pour faire son boulot. A mon avis, la multiplication des libs et des frameworks en Java est une plaie. Vive le POJO.

Par contre, je le suis complètement quand il parle d'UML. Nous avons actuellement un petit projet fait selon des méthodes de nazi que l'on nous a imposés, où on est censés faire une conception détaillée en UML, donc avec signatures de toutes les méthodes, et diagrammes de séquence avec lesdites méthodes pour chacun des use cases, et tout le tremblement. Et développement en Inde.
C'est totalement contre-productif et très frustrant. Pour le gars qui modèle (moi, puis celui qui a pris la suite), parce que cela revient finalement à tout coder dans sa tête sans voir le résultat. Pour les Indiens qui codent parce qu'ils ont un travail sans intérêt qui s'apparente à du coloriage. En plus, le cycle de développement est énormément ralenti. Le résultat est que ça fait 9 mois que ce projet est lancé, avec 1 ingé à temps complet et un archi à temps partiel dessus + x indiens, et il n'y a tjrs pas de version complète du produit, alors que j'avais terminé seul un projet de complexité comparable (voire supérieure) en 5 mois, simplement en codant en Java.

Merci, ajouté à ma liste de clients trad potentiels :)

marche pas avec hfr [:mmmfff]

J'avais bien compris, je critiquais simplement ta tentative d'évitement de la remarque de 0x90 par "le langage va continuer à évoluer"

Oui et non.
Clairement, le langage est aussi complexe que le C++ au niveau conceptuel, même s'il est plus simple au niveau syntaxique. Mais en principe, il évite les chausse-trappes de ce dernier, en étant plus rigoureux et en se basant sur l'expérience acquise pour ce dernier, car Walter analyse à fonds tous les problèmes que l'on rencontre en C++. Les articles qu'il écrit sur la page principale du site sont d'ailleurs toujours lumineux et intéressants (lire l'article sur const, par ex).
Maintenant, il est clair que D est un langage faussement aisé, et nul doute qu'il apportera ses propres chausse-trappes. Cela, seul l'avenir nous le dira. Le truc, c'est que ceux qui risquent de les rencontrer régulièrement sont les power users, ceux qui vont jouer avec les AST pour la métaprogrammation. Les programmeurs lambda, eux, ont à leur disposition un outil en principe bcp plus fiable et sympathique que le C++ (sans être au niveau de simplicité de Java). La seule chausse-trappe que je vois qui risque d'emmerder sérieusement la vie du programmeur lambda est justement la subtilité des const/invariants, sachant qu'en C++, il faut parfois se résoudre à utiliser const_cast.

Oui mais ça veut dire qu'ils n'utilisent pas les nouvelles fonctionnalités pour préserver cette compatibilité. Là, avec la modifictaion de la sémantique de const, c'est différent. Ce n'est pas un simple ajout de fonctionnalité, c'est réellement une incompatibilité avec le code existant, même si les modifs sont probablement assez simples dans la majorité des cas. Et ça veut dire aussi qu'à l'avenir, Walter Bright peut aussi bien décider de faire à nouveau une modif cassant la compatibilité ascendante si besoin est. Un mal pour un bien sans doute, mais plutôt gênant pour les utilisateurs qui maintiennent des projets de grande taille.