Reprise du message précédent :
En ce qui me concerne je suis développeur PHP dans cette boite que je quitte mardi. Je ne parle pas de mes compétences en programmation, je parle de ce qui est utilisé dans le monde financier qui est un gros recruteur en développeur.
 
Demain d'autres technologies seront utilisées, je pense que Java deviendra de plus en plus indispensable dans les années à venir ainsi que .NET

Tu paies un support spécial chez MS qui coûte la peau des fesses pour ses applications officiellement plus supportées (comme Windows NT4). Pour info, VB6 ne sera plus du tout supporté dans 6 mois, il serait temps d'y penser.

Chez nous, on "travaille" la migration. Toutes les semaines, on fait une migration automatisée pis on adapte le code incompatible à coups de scripts maisons. Au début, c'était évidemment trop. Alors quand on a un peu de temps, on travaille le code VB6 pour le rendre plus compatible qu'il ne l'est, pour réduire les efforts post-migration. 140.000 lignes de code, et on estime qu'on peut migrer+rendre 100% fonctionnel en VB.NET en 10 jours, à une personne. Evidemment, après, il faut éliminer le code redondant lié à la gestion pseudo objet de VB6 (qui ne connaît que Implements, et pas Inherits)

Le problème c'est que dans ma boite on travaille pour le milieu boursier avec des centaines de client possédants plusieurs scripts pour chaques choses à gérer, calculer et présenter...
En terme de lignes de codes cela représente plusieurs millions de lignes de code, une base de données à gérer de plusieurs centaines de To... et 4 développeurs dont 2 affiliés uniquement sur les bases Oracles et deux pour tout ce qui est script VB justement
 
Le fait est qu'ils sont au courant des limites de VB6, pour moi un portage vers Java serait extrèmement compliqué et il a été évalué à 4 ans de travail dont un an seulement d'analyse. Pour des raisons de facilités il aurait été pour moi préférable de le porter en VB.NET mais bon ce n'est pas moi qui décide et vu que je termine mardi je m'en fiche royallement.

Va faloir te mettre à jour garçon, le support de VB6 s'est arrêté en Mars 2005, sauf pour l'Extended Support (qui n'est pas donné) qui prendra fin en Mars 2008

COBOL et FORTRAN aussi sont encore très utilisés. Your point?

T'as quasiment 10 ans de retard dans tes prédictions, on entre au contraire dans la phase ou Java va devenir un "legacy language", le cobol du 21e siècle si tu préfères.

Concernant VB, je parle de l'extended Support, certes pas données mais c'est une goutte d'eau dans le budget des entreprises qui en ont besoins
 
Concernant Cobol et Fortan oui ils sont encore très utilisés dans le milieu bancaire (les développeurs cobol se paient à prix d'or maintenant pour la maintenance des systèmes).
 
Au niveau de Java, l'avenir nous dira ce qu'il en adviendra (quid de ses propres évolutions)

Ce qui n'en fait pas de bons langages, ou des langages intéressants, en dehors à la limite d'une niche très précise (pour fortran, et encore)

Pas grand chose.

Ce que je veux dire c'est qu'il y une différence entre les langages "intéressants" et ceux nécessaires et sur lesquels on te demande de bosser.
 
Certes le VB c'est franchement chiant mais c'est un des langages les plus demandés pour des développeurs juniors en SSII.
 
Qu'est ce qu'un bon langage pour toi ? Pespectives futurs ? Perspectives actuelles ? Emploi ? Syntaxe ?

La seule différence c'est la peur de changer de boite.

Sans ordre particulier, productivité (qui inclut la qualité de la stdlib et en partie la synaxe), libs, concepts (nouveaux concepts et concepts différents surtout), extensibilité, communauté (l'intelligence et la qualité de la communauté étant très largement plus importants à mes yeux que sa taille), et enfin maintenabilité du code (oui, un mauvais programmeurs peut faire du mauvais code dans n'importe quel langage tout comme un programmeur fortran peut faire du fortran avec n'importe quoi, mais il existe néamoins des langages aidant et des langages n'aidant pas tans dans leur syntaxe que dans leurs idiômes et coding standards).

Avec également les performances du langage planquée dans un coin, pas d'une importance capitale à mes yeux tant qu'elles sont suffisantes pour la tâche effectuée.

Un langage adapté au projet.

Ca ne veut rien dire ça, pour un projet donné -- à part dans certains domaines précis -- on pourra facilement trouver une douzaine de langages grosso merdo aussi adaptés les uns que les autres (sans parler des restrictions -- à des langages ne faisant pas nécessairement partie de cette liste -- due aux ressources e.g. humaines ou à la couche managériale)

Je prends mon exemple, j'avais un projet de "gestion de projets, génération de documents Word à partir de templates et de records dans MySQL, communication entre les membres d'un projet".
 
Impératif : Multi-Plateforme , technologie WEB, Compatibilité avec une base Ldap et MySQL, utilisation de Ms WORD impératif.
 
Solution donnée : Frontoffice et Backoffice en PHP, Base MySQL, utilisation de la base ldap (domino) via php_ldap, création d'un démon de gestion et de génération de documents en VB (la modifcation de tableaux existant dans un template word (ajouter des lignes....) est difficile en PHP.  
Le tout dans un délai de 10 semaines (analyse comprise)

Si je dis ok pour python, comment cacher mes scripts efficacement ? (si je fais tourner chez des clients par exemple). py2exe ? :-/

Le tout est faisable en Python avec une paire de libs (Python for Windows pour l'interaction avec Word via COM, python-ldap pour le LDAP, et un module Mysql-dbapi2 pour MySQL).

Accessoirement, j'ai l'impression que ta définition de "multi-plateforme" est différente de la mienne, quand on doit impérativement générer des documents spécifiques à windows et qu'on utilise un langage dont le runtime n'existe que sous Windows, j'appelle pas ça du multiplateforme perso...

Te calmer sur l'égo.

Accessoirement, le seul moyen de "cacher tes scripts efficacement", c'est d'utiliser un langage compilé (pour de vrai, en langage machine), il y aura toujours moyen de décompiler le reste.

Et même dans un langage compilé en machine, il y a toujours moyen de le décompiler et de récupérer de l'ASM.

Accessoirement, pour une discu récente sur le sujet voir http://mail.python.org/pipermail/p [...] 97518.html

1) Je ne maitrise pas du tout Python, donc en 10 semaines, apprendre Python et mettre en place la solution c'était pas envisageable.
2) Il fallait une solution client-serveur. Le serveur tourne ici sur Windows (Apache, Php, MySQL), la notion de multi plateforme est en fait lié à l'utilisation d'une solution WEB. Donc utilisable de n'importe ou, sans autre installation qu'un navigateur web quelquonque.

Ca n'a aucun rapport avec ce dont je parlais, je connais python (et je ne suis pas le seul) donc je n'aurais aucun problème à le faire, mais mon point était que ton projet était parfaitement faisable avec une solution autre que celle que tu as choisi, et un langage que je considère comme largement supérieur en tous points aussi bien à VB qu'à PHP (et ce n'est sûrement pas la seule solution alternative, c'est également faisable en C#, et c'est faisable avec n'importe quel autre langage offrant une lib permetant de s'interface avec Word via COM/OLE, genre Perl, Ruby, Java, ...)

Aucun rapport avec du multiplateforme, donc, c'est une webapp, donc c'est multiplateforme par définition à moins d'utiliser des technologies à la con (ActiveX et autres joyeusetés)

Me calmer sur l'ego ? Si je passe pas mal de temps à faire des bibliothèques qui font aussi la valeur ajoutée des traitements que nous vendons, et qu'ils peuvent les récupérer en quelques minutes (voire les refiler à des concurrents avec lesquels ils bossent parfois) ils vont vite se passer de nous comme sous traitants
 
Ok merci pour le lien, je m'y jette.
 
Après quelques posts : ok le pyc ça me va, du moment que ça ne soit pas en texte trop facilement lisible et commenté etc.

En juxtaposant ça aux langages que je maitrise, ca fait pas une douzaine possible par projet , mais un ou deux

Oui

Il est la le problème d'égo, tu considères que tes créations sont si grandioses que quelqu'un va passer du temps à essayer de les récupérer.
 
Et accessoirement, si jamais ça arrivait un jour et que quelqu'un voulait savoir ce que tu as fait et comment tu l'as fait rien ne pourrait l'en empêcher, sauf à avoir tous les traitements sur un serveur distant physiquement inaccessible et juste un client léger servant à afficher les infos du serveur en local. À partir du moment ou quelqu'un a ton application "entre les mains", il pourra aller fouiller ce qu'il y a dedans, même si elle est compilée en code machine.

Lis la partie entre parenthèses à la fin

ok ok;
 
j'ai l'impression que ca forme le gros des cas -- je peux me gourrer et je voudrais pas lancer de débat.

Ce qu'il y a entre parenthèse forme la quasi totalité des contraintes oui, c'est la contrainte "culture de la boite", grosso merdo, et ça existe potentiellement partout (e.g. chez Google, il y a 4 langages de prog permis pour les projets un tant soit peu officiels, ou ayant un jour une chance de le devenir: C++, Java, Python et Javascript)

I love this guy

Je crois (ben oui difficile d'être sur) que ça fait longtemps que j'ai mis ma fierté de côté, trop encombrante
Ma boite vend des prestations (du one shot surtout, même si récurent).
Mes "créations" ne sont pas grandioses, loin de là. Mais j'y ai passé beaucoup de temps, et les clients paient.
 
Bien sur que c'est toujours possible de récupérer, mais si je donne carrément les sources (.py) c'est tout de même un peu plus tentant à lire non ?  
Il y'a même plein de commentaires quelquefois que mes collègues s'y mettent un peu ou qu'il m'arrive quelque-chose.
 
Après si quelqu'un veut en récupérer juste le code à partir d'une (pseudo-)compilation, il passera certainement beaucoup de temps à déduire la logique de la mécanique.

Putain mais on lit n'importe quoi ici, quand on sait pas de quoi on parle on dit rien. Vous y connaissez rien en langages.
 
Le langage par excellence pour commencer est un langage Turing-complet simple, comme le brainfuck. Stou, ya rien à ajouter.
 
jeremy87, crois moi, c'est là que tu trouveras ton bonheur.

Encore faut-il:
1. que les gens se posent la question du langage d'implémentation (il est trivial de mettre un exe à la racine et de planquer les fichiers d'implé dans des répertoires, ou de zipper les modules pour ne pas rendre complètement transparent le fait que ce soit du python)
2. Qu'ils aient le temps et l'envie de lire ce source, ce qui est rarement le cas.

Compiler en -OO et ne filer que les .pyc (le bytecode), ça dégage tous les commentaires et les docstrings, et ça optimise un peu le bytecode.

Voir py2exe aussi, mais à ma connaissance ça fait juste une compilation en bytecode avant de foutre le truc dans un zip wrappé par un exe (en bundlant un interpréteur python et toutes les libs avec)

S'il est bon, pas vraiment, sauf si le code est mauvais

Ah bon ben tant pis pour moi s'il va vite à comprendre. Mais je vois comme ça peut être long parfois même sur les sources je ne me fais pas non plus trop de bile.
Ok la solution des pyc me suffit largement, tu as donné ici une réponse qui me convient. Le py2exe ? Bof non je trouve ça un peu crade.

 
Python est assez simple à prendre en main avec tout ce qu'on trouve sur le net ou avec un bookin a coté c'est easy .
Surtout il a une syntaxe qui oblige d'avoir un code propre au niveau de l'indentation ce qui a mon avis en fait un bon langage pour débuter. Et puis avec toutes les libs dispos, tu peux réaliser une applications assez puissante en quelques lignes de code .
 
Python ownz !

Ben ecoute moi je suis entrain de faire une école d'informatique.
 
Voici ce qu'on apprend:  
1) HTML
2) CSS
3) Java
4) Javascript
5) PHP
...

Et quelle est cette école ?

pas de caml ?

Il parrait que les boucles c'est le mal en Caml

Et alors?
 
Je vais encore plus t'impressionner: en Erlang et en Haskell il n'y a pas de boucles du tout

C'est fini le concours de la plus grosse bite?

Attends je regarde.

 
giver.jpg