Se connecter
Se connecter

ou
Créer un compte

ou
Agrandir
Les Mains dans le Cambouis
Bidouille & Développement Informatique

Sujet Le pub des programmeurs

  • 1 925 réponses
  • 117 participants
  • 119 144 vues
  • 130 followers
1 Le pub des programmeurs
Salut :coucou: y a des programeurs sur AF si oui vous bossez sous quoi ?
Afficher le premier post
501

Hors sujet : Comme disait Coluche: con promis chose due :oops:

Jul

502

Citation :
Quand tu fais de la programmation réseau bas niveau.
Tu sais, quand t'écris tes paquets IP à la main...pour des algos de routage par exemple...
Y'a eu un client Kademlia qui a été tenté en Java, c'est une merde innomable qui te bouffe toute ta RAM (bon c'est aussi en grande partie dûe à la VM).

Ou quand je fais du développement pour téléphone portable et en technos embarqués. Même si la plupart du code est maintenant en NesC (dialecte de C), y'en a quand même en C++.

Du calcul 3D...
Des algos de recherche opérationnelle..

En gros, à chaque fois que les ressources machines peuvent être limitées.



Non mais ce sont des niches, tout ca: programmation reseau bas niveau, moteur graphique, etc... c'est quand meme pas la majorite du code ecrit aujourd'hui. Le code bas niveau est ecrit avec des langages de bas niveau, on est d'accord. Evidemment, la pile IP de linux, elle va pas etre faite en java :) Et les OS courants sont toujours developpes en C a la tres grosse majorite.

Mais meme dans certaines applis que tu cites, on voit des langages haut niveau apparaitre Le premier, evident, qui vient en tete, c'est erlang, pour certaines applis backend de telephonie.

Citation :
Pour la rapidité de prototypage, ben dans les gros softs ce n'est pas recherché, au contraire



Y a pas que le prototypage, il y a aussi la refactorisation.

Citation :
Que signifie "duck typing" ?



If it is behaving like a duck, it is a duck :) En fait, python est un langage type fort, mais c'est jamais verifie dans un appel de fonction. Par exemple:

def foo(a):
return a.bar()

La fonction foo marchera tout le temps tant que a a une fonction bar. Et c'est super utile pour changer en cours de route une api, car si jamais avant a etait derive quelque part d'une classe A, et que maintenant c'est derive de classe B, en C++, tu vois le bordel.

Alors le pendant, c'est que parfois, si tu passes un mauvais object, tu peux avoir un bug (genre une liste au lieu d'une chaine de characteres). Au moins pour les problemes pour lesquels j'utilise python, ca ne ma jamais pose de pb fondamental.

Je suis d'accord que tu vas pas utiliser ca pour du code militaire sensible :) Mais je pense pas etre totalement deconnecte de la realite industrielle niveau informatique, ne serait-ce que parce que je frequente des gens en plein dedans; et les gros projets industriels statiques, c'est pas a la hausse. Alors peut etre que je connais que des gens dans des secteurs particuliers ? Mais en finance, dev web (cote client et cote backend), data mining, calcul distribue/calcul numerique, traitement signal, les langages a la C/C++ sont relegues a des petites parties, avec d'autres langages plus haut niveau pour le reste. Je serais curieux de voir le nombre de developpeurs par type de projet informatique, ca doit etre super interessant.

Le college qui m'a fait decouvrir python, il a bosse 10 ans dans l'industrie du jeu video avant de fonder sa boite de service informatiques pour petites entreprises :) (ex fan de C++ aussi, d'ailleurs). Je pense que l'approche un langage bas niveau pour le gros d'un projet, c'est plus valable aujourd'hui en grosse majorite. La gestion de la memoire a la main, ce sera bientot marginal comme l'est l'assembleur aujourd'hui: indispendable dans certains cas, mais la plupart du temps, la machine (compilateur, VM) le fait mieux.
503

Citation :
la gestion de la memoire a la main, ce sera bientot marginal comme l'est l'assembleur aujourd'hui: indispendable dans certains cas, mais la plupart du temps, la machine (compilateur, VM) le fait mieux.


L'assembleur reste un must have du développeur de haut vol.

Tu n'imagines même pas le nombre de codeurs Java au chômage et le nombre de boite qui cherche des codeurs assembleur...
En Java il faut connaitre au minimum deux frameworks sur le bout des doigts pour être à peu près sûr d'être toujours opérationnel sur un projet quelconque au sein d'une SSII...

Tu parlais de traitement du signal : l'aéronautique, l'aérospatiale, la télépnonie, le transport sont quand même des sacrés industries et elles emploient à prix d'or des codeurs assembleurs et C/C++.
Ce sont des secteurs beaucoup plus que des niches.

Le web est une autre histoire, et il est clair qu'il y a du boulot dans le domaine, notamment en javascript que beaucoup dénigrent.

Je ferais une analyse plutôt différente, car je pense que ce sont les VM qui vont devenir marginales : avec la conversion générale vers l'architecture unique pc pour les terminaux clients, à quoi bon utiliser une VM comme java ?
Sur le marché grand public, java est en net recul (moins de postes possédant une VM).

(j'espère que quelqu'un m'apportera un argument pour garder le système de VM à la java).
Dès que l'on recherche de l'efficacité, le code devient d'autant plus spécifique à l'environnement de la machine et la VM ne sert plus à rien.

Finalement, java est lourd et coûte cher aux entreprises (serveurs hors de prix, environnement complexe).
Gaz de France par exemple en a réellement marre de certains prog java qu'ils ont :
-> les benchs sont hors de prix et les tests unitaires hyper lourds à déployer (étant donnés que ls outils d'analyse pour java sont en java...)

-> les codeurs java des SSII documentent souvent mal, laissent des bugs, récupèrent mal les erreurs, dû à la facilité d'apprentissage du langage qui permet de lancer des codeurs en projet avec deux mois d'expérience. Ceci est plus un problème lié à la politique des SSII quoi qu'il en soit.

-> il faut sortir le bazooka pour péter la mouche, comparé à python ou php (C++ est dans la même m*rde que java pour cela d'ailleurs).

-> lors d'un déploiement d'application sur poste client, il faut vérifier les versions des VM (javasound en est un bon exemple qui ne marche qu'avec d'anciennes VM)...alors que l'on s'assure généralement d'avoir au plus deux ou trois versions d'OS pour l'ensemble de son parc.

-> on se rend compte que le script et le fonctionel ont quand même du bon, que le tout objet à la java est fatiguant.

C'est pour toutes ses raisons que je pense, en tout cas pour java, que les développements sur VM vont progressivement ralentir dans les grands comptes.
Non pas disparaître, mais arréter de progresser.
Je crois au grand retour du compilé ! (ouaiff, pas trop en fait mais bon).

http://soundcloud.com/bat-manson

504
Je trouve aussi que Pov Gabou y va un peu fort avec le C++. Dans mon expérience, j'ai fait de la recherche en industrie et c'était C++. Pourquoi ? Parce que toutes les librairies dont on peut avoir besoin sont écrites en C++. Pendant que Pov Gabou écrit des wrappers, moi je perfectionne mon appli ;) C'est déjà un avantage indéniable du C++ : on perd peu de temps à intégrer des libraries tierces :D

Je suis bien d'accord qu'on peut faire mieux que le C++ niveau langage. D'un autre côté, personne ne t'obliges à utiliser toutes les subtilités du langage : macros, templates... Finalement, avec quelques bonnes habitudes, tu arrives à un C++ épuré, portable et peu sujets aux bugs. En tout cas, je ne connais pas tous les problèmes qu'on peut imputer au C++.

Je suis complètement d'accord avec Dr Pouet, il n'y a pas de bon ou de mauvais langage dans l'absolu, ça dépend du contexte.
505
Je suis parfaitement d'accord avec ta dernière phrase, et je me permets juste d'ajouter que si on enseigne encore aujourd'hui tellement le C, le java, le C++, et pas le python, le "erlang" (coné po du tt)ce n'est pas parce que ce sont des languages basiques, c'est parce que c'est des languages fondamentaux, y a une différence ...
Par rapport à l'assembleur, je nuancerais tout de meme, je suis en DUT GEII ( Electronique Informatique Indus), vous savez là où on programme des microcontroleurs, et microproc, ba ils ont enlevé l'assembleur car apparement les boites recherchent les mecs assez polyvalents pour entrer avec un DUT GEII mais faire un boulot de DUT GEII+DUT Info (+concierge :???: :bravo: ;)).
Donc l'assembleur, c'est encore pratique si tu veux t'amuser à faire vraiment du hard, si t'es sur du tiny tiny et que tu veux avoir une fusée avec une deudeuch de uC ...

Par rapport au système VM, ba je vais pas t'apporter d'arguments contre, mais je pense que ptet que java va aller plus vers le python mnan ...

cptn.io

506
Ben disons que le boulot en assembleur relève maintenant plus d'une compétence d'ingénieur que de technicien, c'est vrai...
En tout cas les débats sur les langages c'est comme le débat des différentes qualité des séquenceurs...
Mais bon, je m'y fais prendre à chaque fois. (vive la polémique héhé.)
Promis, j'arrête.

http://soundcloud.com/bat-manson

507
Dès que les poules auront des dents, moi aussi :mdr: :mdr:

cptn.io

508

Citation : En tout cas les débats sur les langages c'est comme le débat des différentes qualité des séquenceurs...
Mais bon, je m'y fais prendre à chaque fois. (vive la polémique héhé.)


:bravo:
509

Citation :
L'assembleur reste un must have du développeur de haut vol.



Faut etre coherent, avant on parlait de dev de gros projets, maintenant on parle d'assembleur ;) Serieusement, le rapport developpeur assembleur / java, c'est quoi, 1 pour 100, 1 pour 1000 ? En signal, je pense que matlab est plus utile que l'ASM pour trouver un boulot aujourd'hui.

Citation :
Je ferais une analyse plutôt différente, car je pense que ce sont les VM qui vont devenir marginales : avec la conversion générale vers l'architecture unique pc pour les terminaux clients, à quoi bon utiliser une VM comme java ?
Sur le marché grand public, java est en net recul (moins de postes possédant une VM).

(j'espère que quelqu'un m'apportera un argument pour garder le système de VM à la java).
Dès que l'on recherche de l'efficacité, le code devient d'autant plus spécifique à l'environnement de la machine et la VM ne sert plus à rien.



Deja, le coup de la VM super lourde, c'est un argument que j'achete pas du tout. Le but de la VM, ca fait longtemps que c'est plus la portabilite l'argument. MS a sa VM avec .net, et ce sont bien les derniers a s'occuper de portabilite, puisqu'ils marchent avec un OS, une architecture (sur PC du moins; je sais pas si les xbox360 utilisent une VM pour certaines parties).

La VM, c'est un systeme possible pour :
- la securite, une sorte de sandbox. Impossible a realiser en pratique avec du code a la C/C++
- avec des trucs style JIT et cie, ca peut facilement etre aussi voire plus performant que du C.
- c'est aussi un moyen pour surveiller les bornes, etc...

Bref, ca permet de faire au runtime ce qu'il est impossible de faire en statique (surtout avec des langages sous specifies comme le C ou pire le C++).

Mac OS X (je drague pouet, la), version leopard, utilise une machine virtuelle (llvm: https://en.wikipedia.org/wiki/LLVM) pour le pipeline graphique: LLVM peut supprimer au runtime (c'est quoi le mot exact en francais pour runtime ?) des branches inutilisees, ce qu'un langage statique comme le C ne peut pas faire.

Alors evidemment, ca s'adapte pas pour tout, mais dans 10 ans, on verra plus de machines virtuelles (dans le sens large; un interpreteur evolue, pour moi, c'est deja presque une VM), pas moins.

Citation :
inalement, java est lourd et coûte cher aux entreprises (serveurs hors de prix, environnement complexe).
Gaz de France par exemple en a réellement marre de certains prog java qu'ils ont :
-> les benchs sont hors de prix et les tests unitaires hyper lourds à déployer (étant donnés que ls outils d'analyse pour java sont en java...)

-> les codeurs java des SSII documentent souvent mal, laissent des bugs, récupèrent mal les erreurs, dû à la facilité d'apprentissage du langage qui permet de lancer des codeurs en projet avec deux mois d'expérience. Ceci est plus un problème lié à la politique des SSII quoi qu'il en soit.

-> il faut sortir le bazooka pour péter la mouche, comparé à python ou php (C++ est dans la même m*rde que java pour cela d'ailleurs).

-> lors d'un déploiement d'application sur poste client, il faut vérifier les versions des VM (javasound en est un bon exemple qui ne marche qu'avec d'anciennes VM)...alors que l'on s'assure généralement d'avoir au plus deux ou trois versions d'OS pour l'ensemble de son parc.

-> on se rend compte que le script et le fonctionel ont quand même du bon, que le tout objet à la java est fatiguant.



Je suis plus ton raisonnement: tu es en train de dire que parce que java ne marche plus en entreprise, on va revenir au C et au C++, a des langages sans systeme de memoire automatique, sans verification de bornes, etc... ? Les langages fonctionnels, t'es conscient qu'ils marchent tous avec vm ou interpreteur; je connais aucun langage fonctionnel sans gestion de memoire automatique, ca n'aurait vraiment aucun sens. Perl est en train de passer sous pure VM pour la version 6 (mais ca se passe pas super bien, je sais pas pourquoi), y a des efforts dans ce sens pour python, etc...

Tout ton argument, comme je le comprends, il va dans le sens de ce que je disais, cad on s'en va des langages bas niveau style C/C++, etc.. pour aller vers des langages plus haut niveau pour la majorite du code. Le C/C++ etant relegue a ce qu'est l'ASM aujourd'hui; des niches, importants certes, ca disparaitrait pas de sitot, mais des niches.

Si tu me dis que la majorite du code java produit est a chier, je suis d'accord, je suis convaincu que la majorite du code tout court produit est a chier. La majorite des produits informatiques n'est meme jamais deploye, alors bon.

Citation :
Parce que toutes les librairies dont on peut avoir besoin sont écrites en C++. Pendant que Pov Gabou écrit des wrappers, moi je perfectionne mon appli



J'ai developpe avant en C/C++. La librairie standart C ou C++, c'est ridicule par rapport a celle du python; le coup du wrapper, je te reponds que pendant que tu cherches pourquoi t'as un segfault, j'ai le temps d'ecrire une doc correcte ;). J'ai developpe pas mal de code ces dernieres annees en C/C++ + matlab; ma productivite elle a clairement augmente en ajoutant python, elle a pas diminue, crois moi. T'as une librairie standart pour le XML, le reseau, le multi threading, etc...

L'argument du C++ contre python, c'est uniquement performance/latence/occupation memoire pour certains projets, certainement pas les facilites disponibles.

Je le repete: j'ai deja programme du C et du C++, plus que du python en quantite surement, donc je suis conscient des avantages de ces derniers dans certaines conditions.

Le fait est que si tu peux programmer avec un autre langage, tu vas le faire, et tu seras beaucoup plus productif. Je suis persuade que le programmeur a plus d'influence sur la qualite du code, y compris son efficacite, que le langage dans la majorite des cas.

Citation :
c'est parce que c'est des languages fondamentaux, y a une différence ...



Je vois pas ce que tu veux dire ? Si tu connais C, je vois vraiment pa ce que ca t'apporter niveau *concept* le C++ ou meme java. Si tu me disais smalltalk ou python pour de l'objet, lisp, scheme pour du fonctionnel, etc... Je comprendrais. Quand j'ai appris java, j'ai pas eu l'impression de decouvrir un nouveau moyen de programmer, quand meme, par rapport au C/C++; a la limite, ADA m'avait plus marque a l'epoque, par l'etendue de l'analyse syntaxique.

Sinon, Erlang, c'est le langage invente par ericsson. C'est un langage fonctionnel fondamentalement concu pour la programmation concurrente, utilise pour les serveurs http, wap, les switch, etc... chez Ericsson.

Citation :
Je suis complètement d'accord avec Dr Pouet, il n'y a pas de bon ou de mauvais langage dans l'absolu, ça dépend du contexte.



C'est un peu une lapalissade, ce que tu dis. Evidemment que ca depend du contexte. Mon argumentaire, c'est que les contextes dans lesquels on utilise le C++, ils vont diminuant, pas augementant, et que c'est pas juste une mode.
510

Citation : Sinon, Erlang, c'est le langage invente par ericsson. C'est un langage fonctionnel fondamentalement concu pour la programmation concurrente, utilise pour les serveurs http, wap, les switch, etc... chez Ericsson.



Oki d'accord merci, mais bon, perso les languages portés par un seul constructeur j'y crois moyen ... C'est bien pour ceux qui font que du télécom chez Ericsson, et meme ...

cptn.io