Reprise du message précédent :

oué enfin les pauvres ils se payent déjà emacs comme éditeur obligatoire d'entrée de jeu alors que la plupart avaient jamis rien vu d'autre que windows, alors bon leur infliger le lisp là-dessus c'est gore.

ah oui effectivement ça fait un peu mal
 
Zauraient du faire du SML à la place

c'est open source ?

Pour ceux que Reddit pas: http://kawagner.blogspot.com/2007/ [...] erior.html
Perso, suis bien d'accord

Et pourtant il raconte n'importe quoi  
Genre 2e paragraphe

c'est lolzant

 
Now, you explain

Qu'en l'occurence toutes les vraies études / utilisations ont trouvé des différences drastiques de productivité d'un langage à l'autre, soit de manière générale e.g. sur des programmes de taille moyenne càd en dessous de 50kloc ou 100kloc Python ou Ruby sont 3 à 4 fois plus productifs que Java (au dessus la taille des équipes augmente et le typage statique devient un gros avantage, en gardant à l'esprit que le code Python our Ruby est souvent 2 à 3 fois plus petit que le code Java en terme de locs et de statements).
 
Dans des domaines d'application particuliers c'est encore plus effrayant: Joel Reymont, l'auteur d'OpenPoker, a réécrit son serveur en Erlang...
 
Il a fait des recherches et du prototyping dans divers langages (Delphi, Python, C#, C/C++, Scheme, ...) avant de choisir Erlang, la recherche a duré ~9 mois, la réécriture réelle du serveur a pris 6 semaines, la version originale du serveur avait été écrite en 9 mois par une équipe de 5 personnes en Delphi.
 
À noter que par la suite il a regardé ce que donnait Haskell pour des programmes massivement parallèles, tolérants à l'erreur et distribués, et il l'a quelque peu défoncé dans ce cas particulier où Erlang lui est largement supérieur (cf http://wagerlabs.com/2006/12/8/re- [...] -platform/ ). Naturellement, Erlang a été créé pour ça, ça aide.
 
edit: histoire que les gens comprennent bien ce que donne erlang sur un serveur

Il ne donne pas les specs de son laptop, mais c'était en octobre 2005; donc pas vraiment un supermonstre

Masklinn> Surement tous ces langages sont supérieurs et auraient interêt à être utilisé ( c'est d'ailleurs ce que je comprends de l'article hein, pour moi l'auteur parle juste de ce qui rends un langage "populaire" ).
Mais AMHA, la seule chose que tu ne prends pas en compte c'est que 99% des programmeurs/developpeurs n'ont pas 10% de tes connaissances (oui je me mets dedans ).
Alors oui, quand t'es une star tu peux faire tes trucs en ce que tu veux( ou plus exactement en ce qui te fait le plus plaisir / ce qui est le plus adapté) mais dès que tu passes dans un environnement de production les problèmatiques sont différentes .

Même si un langage "exotique" est 10 fois plus adapté, si la productivité sera bien meilleure, ou tout ce que tu voudras; une boite acceptera difficilement de former une equipe à l'utiliser (temps et cout de formation, problème de maintenance si l'equipe se "décompose" ...) sauf si elle sait que le retour sur son investissement sera evident.
En l'occurence, si je demande une formation Haskell on va gentillement m'envoyer faire sur les roses...

 
je quote juste ça pour quand même noter qu'une réécriture bénéficie souvent de l'experience des erreurs de la premiere implémentation et donc tu te poses moins de questions ou tu fais moins d'aller/retours que la premiere fois

 
+1
 
Ensuite il faut pouvoir implanter la solution "exotique" en question sur la plateforme en cours d'utilisation, et ce, toujours à moindre frais, ect...
 

 
+1 J'allais quoté ça aussi, même si, à mon avis on peut difficilement faire un parallèle aussi primitif entre le temps de réécriture et le temps de devel initial étant donné les écarts de production

Ca me ferait très plaisir mais ce n'est malheureusement pas le cas
 

Bien sûr, mais personne ne forme des équipes sur ce genre de choses (sauf cas particulers e.g. Ericsson avec Erlang), ce sont les gens qui connaissent le langage qui décident de l'utiliser à la base puis on oriente le recrutement vers les gens ayant les connaissances nécessaires.
 
Tu vas me rétorquer "mais les gens connaissant ce langage sont beaucoup moins nombreux que ceux qui connaissent le Java!"
 
Effectivement, après c'est un choix (dont Graham parle dans "The Python Paradox" ), un choix entre une pool énorme de développeurs de qualité très variable mais avec une moyenne qualitative extrèmement basse, ou un choix entre un pool beaucoup plus petit, qualitativement plus élevé en moyenne (les gens apprenant des langages peu populaires sont fondamentalement intéressés par leur domaine et par la découverte), probablement plus enthousiastes, et surtout qui n'auront aucun problème à quitter un boulot dans un langage "populaire" pour venir bosser avec un langage qu'ils apprécient.
 
C'est un risque, je ne vais pas tenter de prétendre le contraire, c'est probablement un risque que certains ont pris et sur lesquels ils ont échoué, mais c'est également un risque que certains ont pris et qui a fait leur réussite (À l'origine chez Amazon seuls deux langages étaient autorisés: C et Lisp; la startup qui a originellement créé Yahoo Store l'a fait en Lisp et son fondateur considère que sans Lisp il ne serait jamais arrivé là où il le voulait; Ericsson a créé son langage pour les switches telecoms et l'a utilisé dans l'un de ses switches les plus populaires -- le  AXD301 ATM switch -- et ça a marché au point que des boites comme Nortel, T-Mobile ou Telia s'y sont mis, ...)
 
C'est un risque, je ne peux le nier, mais le plus gros problème est que les gens ne veulent pas évaluer ce risque et se bornent à la mentalité "No One Ever Gets Fired For Buying IBM" de l'époque "Big Iron", qui de nos jours se traduit par "Personne ne s'est jamais fait virer pour avoir choisi Java ou C#". Même si le projet est un échec, les gens qui prennent les décisions peuvent se couvrir le cul, au final ils peuvent dire qu'ils avaient choisi "le standard de l'industrie" et que l'échec ne vient donc pas d'eux.

Au point de passer de 9 mois pour 4 personnes à 6 semaines pour 1 personne?
 
Faudrait éviter d'abuser peut-être

Au final on en arrive au même point qu'avec les OS, y'a des solutions TRES puissantes mais peu répandues, qui sont écrasées par des solutions sans grand intérêt, ou même très fouillies, qui sont elles, TRES connues.

J'utilise php tout les jours, et je trouve ça trop fermé, ou trop permissif, j'aimerais bien proposer d'autres solutions a ma boite, mais quel est l'intérêt quand 90% des mecs autour de moi on la doc php ouverte 90% du temps?

Inferno

Les faire virer

<mylife>
Perso je bosse sur une appli web faite en perl (le coeur on va dire),  originellement perl avait été choisi du fait de traitements sur de gros fichiers ( et aussi a cause de connexion sur un as400 mais c'est une autre histoire)... Et jusqu'à présent c'est un choix qu'on a jamais regretté ( techniquement).
Maintenant ça va faire 18 mois qu'on cherche des gens pour etoffer l'equipe (essentiellement pour faire de la maintenance).
Et bin je peux te dire que c'est la misère car, comme tu le dis plus haut les profils compétents sont rares, pas forcément interessé par de la simple maintenance et ont des pretentions salariales... humm ... je dirais à la hauteur de leurs compétences, mais les rhs disent trop chers.
 
La morale de l'histoire:
- sur les 2 dernières années, 60% des devs sont partis offshore faute de personnel dispo ici; la direction ayant calculé que cela coutait moins chers que de prendre les gens compétents que j'évoquais plus haut. Le discours a quelque peu changé depuis vu les merdes qu'on a sur les-dits developpements.
- on a tenté la conversion de devs debutants php en perl, ça a presque toujours echoué ( 1 sur 9). Mais c'est c'est pas grave pour la boite, car ceux qui ont échoués sont renvoyé en mission ailleurs
 
L'autre morale, c'est qu'on a un site satellite à faire à l'application ou l'utilisation de RoR serait idéal, mais qu'il va être fait en php juste pour pas se retrouver dans la même problématique.
</mylife>
 

Entierement d'accord, mais sur mon exemple précédent, mais si j'ai un pseudo pouvoir de décision, il a été balayé par les arguments du style:

• on a pas les compétences et ça coutera trop cher de former les gens
• même si on les forme, le ruby c'est pas quelque chose que nous demande les clients

Ca me rappelle un débat virulent que j'avais eu sur Direct X 10, pas tant dans la structure du language (quoique, j'en sais rien), mais plus dans le fait que les dev s'orientent vers lui et donc que 99% des jeux PC sortent sur ce format, ensuite découlent un certain nombre de dépendances...

De la, on ferme l'application typée "jeu", à une plateforme

anapajari >
Des points intéressants
(c'est un peu dommage que vous ne trouviez personne pour faire du Perl, surtout si l'appli est bien codée) (elle est bien codée?) (je présume puisque tu dis que vous n'avez pas de regrets)

Oui enfin l'argument des plateformes est très discutable, la grande majorité des langages -- surtout ceux qui ne sont pas très populaires -- tourne sur la quasi totalité des plateformes (sauf obscures genre Inferno ou Plan 9). Tant que le langage ne vient pas de chez microsoft naturellement

C'était bien codé ... jusqu'à ce qu'on fasse appel aux devs offshores. Maintenant c'est plus rocambolesque

De toute façon, je n'ai jamais fait de perl mais j'ai cru comprendre qu'une appli perl mal codée dégénérait très très vite, donc tu n'en aurais pas parlé comme tu l'as fait

 
  Je me suis mal exprimé, je mettais l'accent sur l'échelle d'utilisation du "language", plus que sur la plateforme sur lequel il fonctionnait. En notant bien que la première donnée influe sur la deuxième.
 
On retrouve souvent Microsoft dans ce genre de monopole inexpliqué, c'est bizarre non?

Il serait irrévérencieux de se moquer mais :  
http://forum.hardware.fr/hfr/Progr [...] 2128_1.htm

bah entre 6 bras cassés mal dirigés et qui codent en delphi, et un mec doué qui sait ce qu'il fait dans un language adapté et qu'il maitrise, ça m'etonne pas tant que ça

Les serveurs de 1&1 c'est quand même de la belle merde
 
Entre mes pages qui s'affichent soit normalement soit très lentement et le fait qu'il faille 4 heures pour se connecter au ftp ou changer de répertoire, j'en peux plus

 
Bizarre, je suis chez eux depuis un bout de temps et je ne rencontre pas de problèmes...

j'aime bien, on le sent surtout parti pour rester ....

Ruby on Rails c'est :
 
On lit la doc
On apprécie
On installe
 

Pour quelqu'un qui a de l'expérience je dis pas, mais personnellement j'ai débarqué la dedans (premier boulot) et au départ c'est pas évident de tout comprendre.

De l'expérience dans quoi?
 
Parce que je programme essentielement en actionscript, javascript et php (pour ce qui est du dyn) et j'ai trouvé la syntaxe TRES simple.

Pas exactement en fait, c'est plutôt

• On lit un tutorial
• On installe
• On apprécie
• On cherche la doc
• On cherche la doc
• On cherche la doc

• On cherche la doc
• On finit par acheter le bouquin PARCE QU'IL N'Y A PAS DE DOC UTILISABLE BORDEL §§§

C'est bien souvent le problème ouais, la doc...

Doc 2.0 => Faut fouiller les blogs.
Ou sinon faut faire du Turbogear, la doc de base est mieux foutu, mais pas encore de bouquins pour la montée en puissance, et c'est pas hype.
 
On peut pas tout avoir.

C'est surtout un problème majeur dès qu'on fait du Ruby: il n'y a quasiment pas de doc gratuite (à part des blogs, mais se taper 15 millions de blogs à la recherche d'une putain de doc... surtout que 90% de ce que tu trouves est trivial ou sans intérêt ), et Rails est encore pire que Ruby en général à ce niveau là (j'ai eu du mal à le croire vu la pourrituration de la doc' Ruby)

La doc de Django est également très très bonne, bien meilleur que celle de Rails

C'est une blague? Tu as lu Agile Web Development with Rails? Tu considères vraiment que ça permet une quelconque "montée en puissance"? C'est un tuto géant, c'est une bonne introduction au framework (comme le Pickaxe book est un bon bouquin de ruby) (en fait le Pickaxe 2 est bien meilleur que Agile Web Development with Rails rev2), mais une quelconque "montée en puissance" n'est pas à l'ordre du jour du bouquin

je cherche a faire apparaitre un champs INPUT de type TEXT quand je clique sur un INPUT de type RADIO, c'est faisable facilement ? ou il faut que j'aprenne l'ajax qui va me prendre 3 ans

Apparaitre, le créer, ou apparaitre, rendre accessible?

Un simple JS fera l'affaire, monsieur.
603.000 FF, merci.

C'est quand même une psychose, de voir de l'AJAX de partout lol...

<input type="radio" onclick="document.getElementById('champTexte').style.display='inline';" /> ?

d'autant plus que l'ajax c'est du javascript, à la base

   
Y'a bcp de bouquins sur rails. Agile Web, ce n'est pas qu'un tuto, la seconde version est même assez complète. Ce n'est pas pour rien qu'on le considère comme une référence    
Pour la suite, y'a Ruby for Rails et Rails Recipes qui sont excellents
 
Y'a encore Rails CookBook et Ruby on Rails Up and Running, mais un cran en dessous niveau qualité.