Tout à fait d'accord avec toi, les rares fois ou je l'ai croisé, c'est pour de l'embarqué... Et encore, on retrouve aussi le C++Envoyé par jopopmk
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Tout à fait d'accord avec toi, les rares fois ou je l'ai croisé, c'est pour de l'embarqué... Et encore, on retrouve aussi le C++
L'homme sage apprend de ses erreurs, l'homme plus sage apprend des erreurs des autres. - Confucius -
Ma (petite...) chaine Youtube
Si vous avez quelques minutes, passez donc voir mon site http://www.photospicsandco.fr/
Envie de tee-shirts (et goodies!) originaux et sympa ? Visitez mon site... http://www.zazzle.com/shkyo30
A mon sens, le langage n'est qu'un "détail" de la programmation, il faut bien entendu connaitre les bases (ce qui n'est pas très compliqué) mais chaque langage vient avec son écosystème, ses librairies tierces, ses frameworks voir ces outils de dev adaptés... tout cela pour dire que le langage n'est pas tout !
Pour ma part, je connais et j'utilise un certains nombres de combinaison langage/framework et pour moi c'est cela qui a de la valeur...
Par exemple,
*développement de serveur de calcul en C/C++ avec Boost, OpenMP, MPI...
*développement de service REST en Java, Jax-RS, avec TomEE...
*développement de service REST en Javascript basé sur node.js avec HAPI...
*développement de site web en Javascript avec AngularJS, Framework CSS (bootstrap) ...
Dans ces exemples, je n'utilise uniquement qu'un sous-ensemble des langages... et en générale le langage n'est qu'un détail de la solution mise en place... et ce n'est pas en générale ici que ce trouve la complexité...
Dans le cadre de recrutement ce focaliser uniquement sur un langage me parait une erreur !
Si vous voulez recrutez un développeur d'application web en .NET, par exemple:
Que choisissez vous ?
* un développeur Java produisant des applicatifs web
* un développeur .NET ne produisant que des client lourd Windows
L'industrie française a été détruite, il est donc normal qu'il n'y ait pas de demande pour le C en France puisqu'on ne produit plus d'appareils. Je parie que le C est beaucoup plus important en Allemagne.- le C est la deuxième techno la plus demandée par les employeurs (c'est franchement pas le vécu que j'en ai).
Voilà, rien de bien méchant. Dans l'absolu je suis d'ailleurs plutôt satisfait des résultats de ce classement
Python a de nombreuses qualités mais c'est un langage à typage dynamique et les études empiriques ont démontré de façon incontestable que ce genre de typage n'est pas adapté aux projets de moyenne et grande taille. Par ailleurs les performances sont rapidement problématiques et Cython est aussi moche que Python est élégant (*).
(*) mais pas autant que Ruby bien sûr.
pour ta centrale nucléaire, c'est surtout haskell qu'il te faut.Sans hésiter, C#, C++, pour la Poo et F#, Erlang pour le fonctionnel, le massivement distribué et les trucs qui rox genre piloter une centrale nucléaire.
Et pour le kiff Perl surtout BioPerl
c'est la première fois que je le vois dans un classement et ça c'est une super nouvelle.
prosélytisme on:
je le conseille vraiment à tous ceux qui veulent se dégourdir les neurones pendant l'été.
http://lyah.haskell.fr/
prosélytisme off
Heuuuuuuuu...
Je ne suis pas spécialiste de la question mais Haskell pour du logiciel à hautes garanties (high-assurance) ça me semble être une très très mauvaise idée (à moins de parler d'un dérivé spécialisé) :
* GC avec pauses imprévisibles et de durées indéterminées.
* Allocations sur le tas (on préfère se cantonner à la pile), et en prime des allocations en pagaille du fait des structures immuables.
* Maintenant mélange les deux points précédents et tu n'as plus aucune garantie sur la capacité mémoire suffisante et le temps d'exécution.
* Évaluation paresseuse, ce qui veut dire que chaque lecture d'une pauvre valeur peut en réalité masquer un bazar sans nom dont tu n'auras aucune idée au moment où tu écriras et relias ta fonction. Le flux de contrôle global est indéterminable à moins d'anticiper toutes les possibles chaînes d'appelants.
* La garantie de pureté c'est bien mais allouer 25To de structures de données locales et démarrer 250 threads c'est pur et considéré comme dénué d'effet secondaire.
* Aucune garantie sur l'absence de débordement de pile. Ce qui n'est pas un problème trivial avec la prog fonctionnelle.
* Le problème de la prog fonctionnelle c'est que les fonctions voient leur nombre d'arguments rapidement augmenter dans les programmes réels, et en deviennent indigestes. C'est d'ailleurs pour ça que tous les haskelliens raffolent des noms mono-caractères cryptiques. Mais avoir le choix entre un code cryptique ou indigeste n'est pas particulièrement souhaitable. A mes yeux Haskell est facilement analysable par les logiciels mais difficilement analysable par les humains. Ça se défend mais bon...
Bref, ça va faire un joli ka-boom. Pour ma centrale nucléaire je prendrai du Ada ou du Spark, merci.
houlala,
on est pas du tout sur la même longueur d'onde,
je suis une bille complète, concernant tout ces problèmes de gestion de mémoire, de garbage collector,...
je ne vais pas pouvoir être ton contradicteur.
par contre je trouve haskell très sympa d'un point de vue syntaxe et algorithmique (pour des petits dev perso...),
mais tu m'as un peu titillé, je regarderais ce qu'il y a sous le capot à l'occasion (encore qu'il y a pas mal de compilateurs différents).
d'ailleurs si tu as de la doc sur le sujet, n'hésites pas à partager.
pour ce qui est de l'évaluation paresseuse, je trouve l'idée géniale (sans savoir ce que ça implique en termes de ressources).
enfin pour la gestion de la centrale nucléaire, j'avais plutôt ça en tête :
ka-boom
Le sujet est un peu large et je ne le connais pas suffisamment. Mais sur le fond, dans la prog à hautes garanties on veut en général pouvoir prouver (automatiquement) que telle partie du code aura toujours suffisamment de mémoire et s'exécutera toujours dans un intervalle de temps donné.
Or si tu utilises des mécanismes de type C++ sans soins particuliers tu as tendance à fragmenter la mémoire et celle-ci augmente donc continument, ce qui dégrade les performances (débit et stabilité) et peut aboutir à une saturation après plus heures/semaines/mois/années de fonctionnement continu (certains programmes tournent depuis plus de dix ans sans interruption).
Si a contrario tu utilises une gestion automatisée type ramasse-miettes (GC), les algos classiques impliquent en général de mettre régulièrement chaque thread en pause afin d'énumérer les références sur sa pile d'appels et dans ses registres, puis à la fin pour mettre à jour ces références après compactage.
A la rigueur on peut se débarrasser de ces pauses mais au prix d'une baisse générale des performances du GC. Si bien que les applis temps réel préfèrent souvent conserver les pauses en essayant de multiplier de petites pauses fréquentes mais très courtes. On s'efforce alors de préserver un pourcentage de CPU dispo pour le programme lui-même. Malheureusement il est impossible de fournir des garanties à moins de déclencher manuellement les nettoyages et d'avoir une taille mémoire fixe (on peut prouver le nb maximal de chaque objet).
Note au passage que la durée d'activité du GC est proportionnelle au nombre d'objets en mémoire puisqu'il faut tous les visiter pour détecter des cycles. Au mieux on peut réduire cette charge en visitant seulement les pages mémoires avec des objets récemment modifiés (GC générationnel). Mais si ton programme modifie des objets un peu partout ou que le nb de références s'accroit, alors tu vas vite dégrader les performances.
De ce que j'en sais, dans les applis à hautes garanties on essaye d'avoir un modèle où toutes les allocations sont faîtes sur la pile et la récursion est interdite (sauf tail recursion). Ce sont des limitations drastiques. Du coup aucune gestion mémoire n'est nécessaire et il n'y a aucun aléa temporel indéterminé lié à un allocateur ou un ramasse-miettes. Et il est trivial de prouver que l'espace de la pile ne sera pas dépassé.
Et lorsqu'un constructeur automobile bâcle ces vérifications, cela fait un mort.
Cela dit, écrire des programmes fiables, c'est surtout une question organisationelle et pas seulement technique.
Au passage, concernant l'évaluation paresseuse, ce n'est pas tant un problème de ressources (même si c'est plus coûteux) que de difficulté à prédire le comportement du programme, voire à le comprendre une fois qu'il existe (débogage). Lire une valeur en Haskell ce n'est pas simplement lire une valeur, c'est exécuter le code qui produit cette valeur. Or typiquement tu ne sais pas quel est ce code qui sera exécuté parce qu'il t'es fournit par une autre partie du programme écrite par quelqu'un d'autre ou dont tu ne te rappelles plus.
Le gros souci avec l'évaluation paresseuse c'est que les calculs ne sont pas effectués au moment où tu penses qu'ils le seront, et tu ne sais jamais ce qu'implique vraiment la ligne que tu es en train d'écrire. Pire : les calculs sont parfois exécutés dans un ordre différent que celui auquel tu pensais, ce qui complique fortement la gestion des états persistants (qui restent indispensables : SGBD, fichiers, réseau, etc) et introduit des bogues pernicieux. Il se pourrait d'ailleurs qu'à l'avenir les langages fonctionnels aillent vers une évaluation "lenient" plutôt que "lazy". Tout comme les langages impératifs pourraient aller du "eager" à "lenient" pour introduire une parallélisation automatique (c'est déjà le cas au niveau du CPU puisque les instructions sont exécutées dans le désordre pour masquer la latence).
@DonQuiche,
merci d'avoir pris le temps d'une explication,
et ça amène plein de perspectives de lecture.
Un peu pas exact ces chiffres.
Je compare ma partie : java / C# et moi, je vois que les propositions de postes, surtout dans le tertiaire, c'est bien plus du .Net que du Java.
Tout d'abord il s'agit d'une "popularité", pas d'une mesure des offres professionnelles immédiates. Vois-y plutôt une préfiguration au doigt mouillé du marché dans quelques années. Ça vaut évidemment ce que ça vaut.
Ensuite ton ressenti se base sur le marché français qui est très particulier : peu d'industrie, peu d'éditeurs, peu de B2C, beaucoup de finance, marketing et B2B. Rien de très jouasse pour nous.
absence de visual basic dans la liste : "bizarre"
Il est excellent cet article sur le développement comme il est pratiqué à la NASA.
j'adore quand l'auteur fait la comparaison avec les autres modèles de développement et avec les process des autres disciplines :
"Most people choose to spend their money at the wrong end of the process," says Munson. "In the modern software environment, 80% of the cost of the software is spent after the software is written the first time — they don't get it right the first time, so they spend time flogging it. In shuttle, they do it right the first time. And they don't change the software without changing the blueprint. That's why their software is so perfect."c'est tellement juste.The most important things the shuttle group does — carefully planning the software in advance, writing no code until the design is complete, making no changes without supporting blueprints, keeping a completely accurate record of the code — are not expensive. The process isn't even rocket science. Its standard practice in almost every engineering discipline except software engineering.
Ah que c'est bon de voir ce Php descendre bien en dessous de Python. Je me spécialise Python actuellement et quand je vois que je fais en une heure ce qui me prendrait une journée, pourtant avec dix ans de pratique Php, je commence à haïr Php pour m'avoir fait perdre autant de temps.
.I..
Apprenez d'abord le français !!
Le meilleur langage, c'est d'abord de savoir écrire en français; n'est-ce pas ALIMGAOS ?
Tu voulais dire l'anglais, n'est-ce pas ?
Quels sont les meilleurs outils 2015
- Le marteau
- La pince coupante
- La scie à cloche
- Le tourne-vis plat
- Le tourne-vis++ (a/k/a cruciforme)
- Le burin
- La lime
- Le ciseau à bois
- La clé à pipe
- Le rabot
- Le couteau suisse
En comparaison avec 2014
- Le marteau
- Le tourne-vis plat
- Le tourne-vis++ (a/k/a cruciforme)
- La scie à cloche
- La pince coupante
- La clé à pipe
- La masse
- La lime
- Le couteau suisse
- Le ciseau à bois
- Le rabot
Comme l'IEEE, j'aime classer des choses de manière arbitraire xD.
-- Yankel Scialom
C#
Bonjour,
J'ai développé beaucoup d'applications en delphi qui fonctionnent encore très bien mais en à peine un mois je suis passé sur C# , c'est facile , fonctionnel, plus cohérent et abouti surtout avec visual studio 2013 et le net framework 4.5, et je ne peux plus me passer de entity framework ou sytème similaire comme par exemple xpo devexpress, je vais énormément plus vite dans l'écriture de mes programmes, bref que du bonheur, c'est dur de retourner sur delphi pour maintenir mes anciens programmes.
En fait la raison principal qui m'a obligé de migrer c'est que des bibliothèques comme TELERIK , DEVEXPRESS etc... n'existent pas sur Delphi, car j'ai besoins de faire des applicatifs de plus en plus aboutis.
En plus le coté déclaratif de Delphi me faire perdre du temps.
Ce serait plutôt :
* Le marteau.
* Le marteau++ customisé par l'URSS en 1970, avec arrache-clous et grenade à l'arrière.
* La pelleteuse C#, pour les chantiers où les ouvriers sont habillés en bleu.
* La pelleteuse Java, pour les chantiers où les ouvriers sont habillés en vert.
* La pelleteuse Swift, pour les chantiers où les ouvriers sont tenus de se présenter en queue-de-pie avec cinq points de contrôle à l'entrée.
* La tronçonneuse Ruby
* La tronçonneuse Python
* La tronçonneuse PHP, bien connue pour avoir déplacer la poignée au milieu de la lame.
* Le marteau-piqueur Javascript sans atténuateur de décibels mais avec four à micro-ondes intégré et machine à laver en option. Légalement imposé à tous les ouvriers depuis 2000, y compris ceux qui n'ont pas l'usage d'un marteau-piqueur.
* La calculatrice R.
c'est bizarre comme je n'aime pas l'humour français, ça sert à rien et c'est pas constructif, je discute avec le monde entier, développeurs américains et russes mais en france c'est difficile , c'est la dernière fois que je parle sur ce forum.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager