Y a-t-il une raison d'utiliser C ++ au lieu de C, Perl, Python, etc.?
En tant que développeur Linux (côté serveur), je ne sais pas où et pourquoi devrais-je utiliser C++.
Quand je vais pour la performance, le premier et dernier choix est C.
Lorsque la "performance" n'est pas le problème principal, les langages de programmation comme Perl et Python seraient de bons choix.
Presque toutes les applications open source que je connais dans ce domaine ont été écrites en C, Perl, Python, script Bash, AWK ou même PHP, mais personne n'utilise C++ .
Je ne parle pas d'autres domaines comme l'interface graphique ou les applications Web, je parle juste de Linux, CLI et démons.
Y a-t-il une raison satisfaisante d'utiliser C++?
Quand je vais à la performance, le premier et dernier choix est C.
Et c'est là que vous devez sauvegarder. Maintenant, je ne peux pas du tout , parler pour le développement du serveur. Il n'y a peut-être en effet aucune raison impérieuse de préférer le C++ aux alternatives.
Mais de manière générale, la raison d'utiliser C++ plutôt que d'autres langages est en effet la performance. La raison en est que C++ offre un moyen d'abstraction qui a, contrairement à tous les autres langages que je connais, aucune surcharge de performances lors de l'exécution.
Cela permet d'écrire du code très efficace qui a toujours un niveau d'abstraction très élevé.
Considérez les abstractions habituelles: fonctions virtuelles, pointeurs de fonction et idiome PIMPL. Tous ces éléments reposent sur une indirection résolue à l'exécution par l'arithmétique des pointeurs. En d'autres termes, cela entraîne un coût de performance (aussi petit soit-il).
C++, d'autre part, offre un mécanisme d'indirection qui n'engendre aucun (performance) cost: templates. (Cet avantage est payé avec un temps de compilation (parfois énormément) augmenté.)
Prenons l'exemple d'une fonction de tri générique.
En C, la fonction qsort prend un pointeur de fonction qui implémente la logique selon laquelle les éléments sont ordonnés les uns par rapport aux autres. La fonction Arrays.sort De Java se décline en plusieurs variantes; L’un d’eux trie des objets arbitraires et nécessite de lui passer un objet Comparator qui fonctionne comme le pointeur de fonction dans le qsort de C. Mais il existe plusieurs surcharges supplémentaires pour les types "natifs" Java. Et chacun d'eux a sa propre copie de la méthode sort - une duplication de code horrible.
Java illustre une dichotomie générale ici: soit vous avez une duplication de code, soit vous subissez une surcharge d'exécution.
En C++, la fonction sort fonctionne un peu comme qsort en C, avec une petite mais fondamentale différence: le comparateur qui est passé dans la fonction est un modèle paramètre. Cela signifie que son appel peut être en ligne . Aucune indirection n'est nécessaire pour comparer deux objets. Dans une boucle étroite (comme c'est le cas ici), cela peut réellement faire une différence substantielle.
Sans surprise, la fonction C++ sort surpasse les sort de C même si l'algorithme sous-jacent est le même. Cela est particulièrement visible lorsque la logique de comparaison réelle est bon marché.
Maintenant, je ne dis pas que C++ est a priori plus efficace que C (ou d'autres langages), ni qu'il offre a priori une abstraction plus élevée. Ce qu'il propose est une abstraction qui est très élevée et incroyablement bon marché en même temps, de sorte que vous n'avez souvent pas besoin de choisir entre un code efficace et réutilisable.
Je vois beaucoup trop de programmeurs C qui détestent C++. Il m'a fallu un certain temps (des années) pour comprendre lentement ce qui est bon et ce qui est mauvais à ce sujet. Je pense que la meilleure façon de le formuler est la suivante:
Moins de code, pas de temps d'exécution, plus de sécurité.
Moins nous écrivons de code, mieux c'est. Cela devient rapidement clair pour tous les ingénieurs qui visent l'excellence. Vous corrigez un bug en un seul endroit, pas beaucoup - vous exprimez un algorithme une fois, et le réutilisez dans de nombreux endroits, etc. Les Grecs ont même un dicton, remontant aux anciens Spartiates: "dire quelque chose en moins de mots, signifie que vous êtes sage à ce sujet ". Et le fait est que lorsqu'il est utilisé correctement , C++ vous permet de vous exprimer en beaucoup moins de code que C, sans coûter la vitesse d'exécution, tout en étant plus sûr (c.-à-d. captant plus d'erreurs au moment de la compilation) que C.
Voici un exemple simplifié de mon rend : lors de l'interpolation des valeurs de pixels sur la ligne de balayage d'un triangle. Je dois partir d'une coordonnée X x1 et atteindre une coordonnée X x2 (de gauche à droite d'un triangle). Et à chaque étape, à travers chaque pixel que je passe, je dois interpoler des valeurs.
Lorsque j'interpole la lumière ambiante qui atteint le pixel:
typedef struct tagPixelDataAmbient {
int x;
float ambientLight;
} PixelDataAmbient;
...
// inner loop
currentPixel.ambientLight += dv;
Lorsque j'interpole la couleur (appelée ombrage "Gouraud", où les champs "rouge", "vert" et "bleu" sont interpolés par une valeur de pas à chaque pixel):
typedef struct tagPixelDataGouraud {
int x;
float red;
float green;
float blue; // The RGB color interpolated per pixel
} PixelDataGouraud;
...
// inner loop
currentPixel.red += dred;
currentPixel.green += dgreen;
currentPixel.blue += dblue;
Lorsque je rend dans l'ombrage "Phong", je n'interpole plus une intensité (ambientLight) ou une couleur (rouge/vert/bleu) - j'interpole un vecteur normal (nx, ny, nz) et à chaque étape, je dois re -calculer l'équation d'éclairage, sur la base du vecteur normal interpolé:
typedef struct tagPixelDataPhong {
int x;
float nX;
float nY;
float nZ; // The normal vector interpolated per pixel
} PixelDataPhong;
...
// inner loop
currentPixel.nX += dx;
currentPixel.nY += dy;
currentPixel.nZ += dz;
Maintenant, le premier instinct des programmeurs C serait "diable, écrivez trois fonctions qui interpolent les valeurs et appelez-les en fonction du mode défini". Tout d'abord, cela signifie que j'ai un problème de type - avec quoi puis-je travailler? Mes pixels sont-ils PixelDataAmbient? PixelDataGouraud? PixelDataPhong? Oh, attendez, dit le programmeur C efficace, utilisez une union!
typedef union tagSuperPixel {
PixelDataAmbient a;
PixelDataGouraud g;
PixelDataPhong p;
} SuperPixel;
..et puis, vous avez une fonction ...
RasterizeTriangleScanline(
enum mode, // { ambient, gouraud, phong }
SuperPixel left,
SuperPixel right)
{
int i,j;
if (mode == ambient) {
// handle pixels as ambient...
int steps = right.a.x - left.a.x;
float dv = (right.a.ambientLight - left.a.ambientLight)/steps;
float currentIntensity = left.a.ambientLight;
for (i=left.a.x; i<right.a.x; i++) {
WorkOnPixelAmbient(i, dv);
currentIntensity+=dv;
}
} else if (mode == gouraud) {
// handle pixels as gouraud...
int steps = right.g.x - left.g.x;
float dred = (right.g.red - left.g.red)/steps;
float dgreen = (right.g.green - left.a.green)/steps;
float dblue = (right.g.blue - left.g.blue)/steps;
float currentRed = left.g.red;
float currentGreen = left.g.green;
float currentBlue = left.g.blue;
for (j=left.g.x; i<right.g.x; j++) {
WorkOnPixelGouraud(j, currentRed, currentBlue, currentGreen);
currentRed+=dred;
currentGreen+=dgreen;
currentBlue+=dblue;
}
...
Sentez-vous le chaos s'infiltrer?
Tout d'abord, une seule faute de frappe suffit pour faire planter mon code, car le compilateur ne m'arrêtera jamais dans la section "Gouraud" de la fonction, pour accéder réellement au ".a". (ambiantes). Un bogue non détecté par le système de type C (c'est-à-dire pendant la compilation), signifie un bogue qui se manifeste au moment de l'exécution et nécessitera un débogage. Avez-vous remarqué que j'accède à left.a.green Dans le calcul de "dgreen"? Le compilateur ne vous l'a sûrement pas dit.
Ensuite, il y a de la répétition partout - la boucle for est là autant de fois qu'il y a de modes de rendu, nous continuons à faire "droite moins gauche divisée par pas". Moche et sujet aux erreurs. Avez-vous remarqué que je compare en utilisant "i" dans la boucle Gouraud, alors que j'aurais dû utiliser "j"? Le compilateur est à nouveau silencieux.
Qu'en est-il de l'échelle if/else/pour les modes? Et si j'ajoute un nouveau mode de rendu, dans trois semaines? Vais-je me rappeler de gérer le nouveau mode dans tous les "if mode ==" de tout mon code?
Comparez maintenant la laideur ci-dessus, avec cet ensemble de structures C++ et une fonction de modèle:
struct CommonPixelData {
int x;
};
struct AmbientPixelData : CommonPixelData {
float ambientLight;
};
struct GouraudPixelData : CommonPixelData {
float red;
float green;
float blue; // The RGB color interpolated per pixel
};
struct PhongPixelData : CommonPixelData {
float nX;
float nY;
float nZ; // The normal vector interpolated per pixel
};
template <class PixelData>
RasterizeTriangleScanline(
PixelData left,
PixelData right)
{
PixelData interpolated = left;
PixelData step = right;
step -= left;
step /= int(right.x - left.x); // divide by pixel span
for(int i=left.x; i<right.x; i++) {
WorkOnPixel<PixelData>(interpolated);
interpolated += step;
}
}
Maintenant, regardez ça. Nous ne faisons plus de soupe de type union: nous avons des types spécifiques pour chaque mode. Ils réutilisent leurs trucs communs (le champ "x") en héritant d'une classe de base (CommonPixelData). Et le modèle fait que le compilateur CRÉE (c'est-à-dire, génère du code) les trois fonctions différentes que nous aurions écrites nous-mêmes en C, mais en même temps, étant très strict sur les types!
Notre boucle dans le modèle ne peut pas gaffer et accéder aux champs invalides - le compilateur aboie si nous le faisons.
Le modèle exécute le travail commun (la boucle, augmentant de "pas" à chaque fois), et peut le faire d'une manière qui NE PEUT PAS provoquer d'erreurs d'exécution. L'interpolation par type (AmbientPixelData, GouraudPixelData, PhongPixelData) se fait avec la operator+=() que nous ajouterons dans les structures - qui dictent fondamentalement comment chaque type est interpolé.
Et voyez-vous ce que nous avons fait avec WorkOnPixel <T>? Nous voulons faire un travail différent par type? Nous appelons simplement une spécialisation de modèle:
void WorkOnPixel<AmbientPixelData>(AmbientPixelData& p)
{
// use the p.ambientLight field
}
void WorkOnPixel<GouraudPixelData>(GouraudPixelData& p)
{
// use the p.red/green/blue fields
}
C'est-à-dire que la fonction à appeler est décidée en fonction du type. Au moment de la compilation!
Pour le reformuler à nouveau:
- nous minimisons le code (via le modèle), en réutilisant les parties communes,
- nous n'utilisons pas de vilains hacks, nous gardons un système de type strict, afin que le compilateur puisse nous vérifier à tout moment.
- et le meilleur de tous: rien de ce que nous avons fait n'a d'impact sur l'exécution. Ce code s'exécutera JUSTE aussi vite que le code C équivalent - en fait, si le code C utilisait des pointeurs de fonction pour appeler les différentes versions
WorkOnPixel, le code C++ sera PLUS RAPIDE que C, car le compilateur s'alignera l'appel de spécialisation de modèleWorkOnPixelspécifique au type!
Moins de code, pas de temps d'exécution, plus de sécurité.
Est-ce à dire que C++ est le tout-et-le-bout des langages? Bien sûr que non. Vous devez toujours mesurer les compromis. Les ignorants utiliseront C++ alors qu'ils auraient dû écrire un script Bash/Perl/Python. Les débutants en C++ heureux de déclencher créeront des classes imbriquées profondes avec héritage multiple virtuel avant de pouvoir les arrêter et les envoyer. Ils utiliseront une méta-programmation complexe Boost avant de réaliser que ce n'est pas nécessaire. Ils utiliseront TOUJOURS char*, strcmp et des macros, au lieu de std::string Et des modèles.
Mais cela ne dit rien de plus que ... regardez avec qui vous travaillez. Il n'y a pas de langage pour vous protéger des utilisateurs incompétents (non, pas même Java).
Continuez à étudier et à utiliser C++ - ne faites pas trop de conception.
RAII pour le bébé gagnant.
Sérieusement, la destruction déterministe en C++ rend le code beaucoup plus clair et plus sûr sans aucune surcharge.
Y a-t-il une raison satisfaisante d'utiliser C++?
Modèles et STL. Vous échangez un peu de temps de construction (et certains messages d'erreur potentiellement incompréhensibles) contre beaucoup d'outils d'abstraction et d'économie de travail utiles, sans impact appréciable sur les performances d'exécution (bien que l'empreinte binaire puisse être un peu plus grand).
Il faut un certain temps pour envelopper votre tête (cela m'a pris quelques années avant qu'il ne clique), mais une fois que vous le faites, cela peut rendre la vie beaucoup plus simple.
Le traitement de texte en C++ est ordres de grandeur moins pénible qu'en C.
Oui.
Si vous recherchez une efficacité exécutable, vous êtes en C ou C++, donc je vais me concentrer sur cela.
Même avant que les modèles ne soient courants, j'ai préféré utiliser C++ plutôt que C pour les types d'exécutables dont vous discutez dès le milieu des années 1990 pour deux raisons très simples: polymorphisme d'objet et RAII .
J'ai utilisé des objets polymorphes C++ pour toutes sortes de choses intéressantes. Par exemple, je travaillais sur un système Linux embarqué avec des superpositions de tampons de trame sur les processeurs OMAP et XScale ARM. Les deux architectures matérielles ont des fonctionnalités de superposition différentes avec des API très différentes. J'ai utilisé un virtuel commun " Overlay "classe de base pour exposer une vue idéalisée des superpositions, puis a écrit les classes" OmapOverlay "et" XScaleOverlay "qui ont été instanciées de manière appropriée au moment de l'exécution, selon l'architecture sur laquelle le code a détecté qu'il s'exécutait.
Pour simplifier à l'excès, RAII est l'idée que vous allouez des ressources connectées à un objet pendant le constructeur de l'objet, ou peut-être plus tard dans la vie de l'objet, et les ressources sont désallouées ou libérées dans le destructeur de l'objet. C'est vraiment sympa en C++, car les objets qui sont des variables automatiques sont détruits lorsqu'ils sortent du domaine. Pour quelqu'un qui est également compétent en C et C++, il est beaucoup plus facile d'éviter les fuites de ressources et de mémoire en C++. Vous ne voyez pas non plus beaucoup de code C++ avec le meme C très courant d'une étiquette à la fin d'une fonction précédant un tas d'appels à free(), et divers goto dans le bloc fonction sauter là-bas.
Je suis pleinement conscient que vous pouvez faire toutes ces choses avec C - c'est juste beaucoup plus de travail, beaucoup plus de lignes de code, et ce que vous obtenez est beaucoup plus laid et souvent plus difficile à comprendre. Il y a du code de polymorphisme tout au long des serveur X internes, et l'homme, est-il énormément et bizarre et souvent difficile à suivre.
Je travaille également beaucoup avec les technologies GNOME comme GTK + et Clutter, qui sont toutes écrites en C à l'aide du système GObject. GObject est comme le système d'objets C++ avec la couverture Nice retirée et tous les internes laids exposés, et il nécessite généralement une demi-douzaine de lignes de code pour faire ce qu'un appel de méthode C++ sur une seule ligne ferait. J'écris actuellement ClutterActors, et bien que les mathématiques soient vraiment intéressantes, je pense constamment: "Tout cela serait tellement plus succinct et compréhensible en C++".
Je pense aussi souvent: "Vous savez, si j'écrivais ceci en C++ au lieu de C, je serais dans le salon à regarder MythBusters avec ma femme au lieu de m'asseoir dans mon bureau à 21 heures. . "
C++ est à peu près aussi rapide que C (certaines choses sont plus rapides, d'autres plus lentes), et il offre de meilleures abstractions et une meilleure organisation. Les classes fonctionnent de manière similaire aux types primitifs, permettant d'utiliser de grandes quantités de code sans être pris en compte. La surcharge des opérateurs et les modèles permettent d'écrire du code qui fonctionne mieux si les représentations des données changent. Les exceptions peuvent faciliter la gestion des erreurs. Le compilateur peut être utilisé pour vérifier plus de choses au moment de la compilation.
Le prix à payer est une courbe d'apprentissage assez désagréable, et il est plus facile d'y faire des erreurs subtiles que la plupart des autres langues que je connais.
Donc, je ne peux pas dire s'il vaudrait la peine pour vous de l'apprendre pour ce que vous faites maintenant. Vous pouvez certainement vous en tirer avec des combinaisons de Python ou Perl et C, mais C++ offre à la fois l'abstraction et les performances dans un package difficile à utiliser.
Je considère le C++ comme un langage des années 1990, un langage d'une époque révolue.
À l'époque, il était important car il offrait des constructions et des mécanismes de langage de niveau supérieur à un coût inférieur en termes de performances. C'était l'outil universel pour tout développer, des applications de carnet d'adresses aux logiciels avioniques, et qui a inspiré l'engouement OO. OOP résolu la faim et le sida, et oui, Je blâme C++ d'avoir essayé de me laver le cerveau à la fin des années 1990 lorsque j'ai commencé à programmer que tout langage non-OO ne valait pas la peine d'être appris.
Maintenant que le matériel a tellement avancé et que des langages modernes plus récents sont apparus, je ne vois pas C++ rester un choix pertinent pour la plupart des programmes d'application, sauf pour les logiciels intensifs en calcul où vous avez encore besoin d'abstraction (jeux, simulations physiques, CAD systèmes, etc.) Même ce dernier peut être évité si vous écrivez un moteur compact et modulaire en C et avez une logique d'application de niveau supérieur déléguée à un langage de script soigné.
Si vous devez descendre dans le métal, utilisez C en toute sécurité, et lorsque vous devez aller de haut niveau, faites-le dans un langage moderne qui n'annonce pas l'encapsulation tandis que vous pouvez modifier librement chaque octet via un pointeur.
selon Linus , non:
Quand j'ai regardé le code source de Git pour la première fois, deux choses m'ont paru bizarres: 1. C pur par opposition à C++. Je ne sais pas pourquoi. Veuillez ne pas parler de portabilité, c'est BS.
[~ # ~] vous [~ # ~] êtes plein de conneries.
C++ est un langage horrible. Il est rendu plus horrible par le fait que beaucoup de programmeurs de qualité inférieure l'utilisent, au point qu'il est beaucoup plus facile de générer de la merde totale et totale avec. Franchement, même si le choix de C ne faisait rien mais gardait les programmeurs C++ à l'extérieur, ce serait en soi une énorme raison d'utiliser C.
En d'autres termes: le choix de C est le seul choix sensé. Je sais que Miles Bader a dit en plaisantant "pour te faire chier", mais c'est en fait vrai. Je suis arrivé à la conclusion que tout programmeur qui préférerait que le projet soit en C++ sur C est probablement un programmeur que je préférerais vraiment pisser off, afin qu'il ne vienne pas foutre un projet avec lequel je suis impliqué.
C++ conduit à de très mauvais choix de conception. Vous commencez invariablement à utiliser les fonctionnalités de la bibliothèque "Nice" du langage comme STL et Boost et autres conneries totales et absolues, qui peuvent "vous aider" à programmer, mais provoquent:
une douleur infinie quand ils ne fonctionnent pas (et quiconque me dit que STL et surtout Boost sont stables et portables est tellement plein de BS que ce n'est même pas drôle)
modèles de programmation abstraits inefficaces où deux ans plus tard, vous remarquez qu'une certaine abstraction n'était pas très efficace, mais maintenant tout votre code dépend de tous les modèles d'objets Nice qui l'entourent, et vous ne pouvez pas le corriger sans réécrire votre application.
En d'autres termes, la seule façon de faire du C++ bon, efficace et au niveau du système et portable finit par vous limiter à toutes les choses qui sont fondamentalement disponibles en C. Et limiter votre projet à C signifie que les gens ne vissent pas ça et cela signifie également que vous obtenez beaucoup de programmeurs qui comprennent réellement les problèmes de bas niveau et ne gâchent pas les choses avec une merde de "modèle d'objet" idiot.
Je suis donc désolé, mais pour quelque chose comme git, où l'efficacité était un objectif principal, les "avantages" de C++ ne sont qu'une énorme erreur. Le fait que nous fassions aussi chier les gens qui ne peuvent pas voir cela n'est qu'un gros avantage supplémentaire.
Si vous voulez un VCS écrit en C++, allez jouer avec Monotone. Vraiment. Ils utilisent une "vraie base de données". Ils utilisent de "belles bibliothèques orientées objet". Ils utilisent "Nice abstractions C++". Et très franchement, à la suite de toutes ces décisions de conception qui semblent si attrayantes pour certaines personnes CS, le résultat final est un gâchis horrible et incontrôlable.
Mais je suis sûr que vous l'aimeriez plus que git.
Linus
Je ne pense pas qu'il y ait de raison impérieuse d'utiliser C++. Si vous voulez faire de la programmation OO, vous pouvez utiliser Python à la place et écrire les parties qui nécessitent des performances rapides en C.
EDIT: Il existe d'autres langages qui s'interfacent bien avec C, donc si vous n'aimez pas Python, il existe des alternatives.
Y a-t-il une raison d'utiliser C++? Certainement.
Certaines personnes pourraient simplement préférer en utilisant C++ sur d'autres options. Demander s'il y a une raison d'utiliser C++, c'est comme demander pourquoi nous avons besoin de centaines de saveurs de crème glacée. Tout le monde n'aime pas simplement s'en tenir à la vanille.
Si les développeurs sont déjà très compétents avec C++, la question pour eux peut ne pas être "pourquoi l'utiliser?", Mais plutôt "pourquoi pas?". Il semble y avoir cette tendance anti-C++ à la mode en SO en ce moment, mais croyez-le ou non, tout le monde n'y souscrit pas. Certaines personnes peuvent simplement aimer le C++ mieux que les autres langages.
Le C++ nécessite-t-il d'être utilisé pour les applications? Bien sûr que non. Mais cette même question exacte peut également être posée pour toute autre langue. Il y a très, très peu de cas où une langue particulière doit être utilisée pour une application.
Je passe juste du C au C++, et je pense que le gain est considérable, même si vous n'avez pas besoin de modèles et de POO.
- Meilleure gestion de la mémoire
- Système de type plus fort
- Une meilleure bibliothèque standard
- Espaces de noms
- etc.
Je suis surpris que personne ne l'ait encore mentionné, mais C++ nous a présenté références , qui résout presque tous les problèmes et pièges des pointeurs:
void ModifyVar(int& var)
{
var = 5;
}
int test = 4;
ModifyVar(test);
Au lieu de:
void ModifyVar(int * var)
{
*var = 5;
}
int test = 4;
ModifyVar(&test);
Beaucoup plus sûr et plus facile aussi ... et sans frais généraux de passage par valeur.
L'endroit et le pourquoi vont généralement être:
- familiarité
- fonctionnalités linguistiques souhaitées
- bibliothèques spécifiques que vous souhaitez utiliser
- exigences de performance
Pour la programmation côté serveur, vous pouvez souvent choisir parmi une myriade de langues différentes, compilées ou interprétées. Habituellement, le choix de la langue dépend de la plateforme sur laquelle vous ou votre équipe serez le plus efficace. Ou si vous n'avez pas encore d'équipe, la disponibilité des compétences sur le marché.
En passant, je ne comprends pas vraiment de décider d'utiliser C/C++ en fonction des performances (uniquement) car de nombreux langages de script sont extensibles avec C/C++. Vous bénéficiez d'un langage de développement rapide couplé à la possibilité de migrer les portions lentes vers des extensions C/C++. Certes, si vous faites de la programmation de systèmes où chaque opération compte, c'est compréhensible, mais dans la plupart des développements d'applications, je ne comprends pas.
C++ vs Python vs Perl ne peut pas être jugé facilement. Cela dépend du projet et des exigences.
C++ possède un arsenal d'utilitaires d'il y a longtemps, fonctionnant sur de nombreuses plates-formes. Mais il est douloureux de commencer à parcourir les flux pour simplement passer String à Integer et inverser.
C++, d'autre part, a un gros problème avec les dépendances sur les bibliothèques. Une fois que vous avez compilé quelque chose dans GCC X ou VC++ Y, vous ne pouvez pas compter que le code sera exécuté par la prochaine version de ces outils. Le même enfer est sur Windows, le même enfer est aussi sur Unix.
Perl, tire sa puissance du monde Unix mais surtout comme outil d'expression régulière. C'est ce qu'il est utilisé la plupart du temps. Avec quelques outils assez sérieux qui même Java ne peut pas le faire d'une manière normale (découvrez comment télécharger un fichier sur un serveur Web), Perl est "juste le faire").
Python est facile, flexible et un langage dynamique. Si simple que vous pouvez envoyer un entier à une fonction, le script attend une chaîne, mais vous pouvez avoir un résultat! Inattendu cependant, mais un résultat. Le programmeur doit donc être très prudent. INACTIF offre un débogage, mais lorsque vous avez TELNET sur un système ou SSH sur trois niveaux et que vous voulez trouver votre problème, le le débogueur ne sera pas là pour se tenir à côté de vous. Mais, il peut faire un excellent travail mathématique rapidement.
Java est un écosystème de mots à la mode, de technologies extraterrestres et de grands mots et lorsque vous souhaitez simplement télécharger un fichier sur le serveur Web, vous constatez que vous ne pouvez le faire que si le serveur possède JSP . Si vous voulez appeler des bibliothèques système ou des fonctions système comme la surveillance, vous devez beaucoup creuser. Et peut-être pour atteindre JNI et OK ... vous pensez alors ... "Pourquoi, Seigneur?"
En dehors de cela, Java est un excellent outil pour les suites d'affaires, et le multithreading, je l'ai beaucoup aimé.
Rapide pour faire un programme et montrer à votre CV "Oh, je connais aussi cette technologie" et votre futur patron, étonnez-vous! Même si, la technologie n'est peut-être pas nécessaire ... (OK, les amis, je déteste le Spring Framework ....)
Linux? Qu'en est-il du "Pascal orienté objet" ou du "D"?
Suggestions:
La chose à garder à l'esprit lors du choix d'une langue est de savoir quels avantages vous en tirerez et combien de temps il vous faudra pour l'obtenir.
L'idée principale entre des langages comme python et Perl est de faire plus avec moins de temps de travail, mais avec plus de temps de processeur. En fait, vous passerez plus de temps à coder un script python ou Perl qu'il ne sera exécuté, mais vous comprenez mon point.
L'avantage du C/C++ est qu'il est rapide, mais à un coût de syntaxe et de typage fort: vous devez faire beaucoup de choses vous-même pour que l'ordinateur n'ait pas à le choisir au moment de la compilation.
Lorsque vous créez un code, certaines lignes seront exécutées beaucoup plus que d'autres, et ces lignes sont celles qui posent problème. En revanche, tout le reste du code, celui sur lequel vous avez passé beaucoup de temps, est exécuté beaucoup moins souvent. Vous l'avez peut-être entendu, mais c'est la fameuse règle 80/20, et vous ne pourrez pas contourner cette règle.
La solution à ce problème consiste à utiliser un langage plus simple (par plus facile, je veux dire plus convivial pour les développeurs: moins de dactylographie, d'interprétation paresseuse, beaucoup de routines et d'autres choses préexistantes, etc.) pour faire tout votre code.
Vous le ferez si rapidement par rapport à si vous l'auriez fait avec C ou C++, cela aurait pris beaucoup plus de mal au cerveau.
Votre programme sera lent, mais avec un profileur, vous isolez la partie qui est exécutée 80% du temps, et vous les faites en C ou C++.
En programmant de cette façon, vous avez économisé beaucoup de temps, et votre programme est aussi efficace, aussi rapide, a beaucoup moins de chances de perdre de la mémoire, et vous avez gagné du temps.
Les langages de script ont été conçus pour être du côté du développeur, mais l'optimisation est toujours possible. Bien sûr, vous pouvez être un magicien du modèle de conception ou un vaudou STL ou même un guerrier LISP, et peut-être un moine haskell. Mais les langues nous font parler aux ordinateurs, les langues ne sont pas faites pour que nous soyons des ordinateurs!
Le C++ que j'utilise s'appelle C avec des classes!
Non pas du tout. Si vous n'avez pas besoin des performances et qu'il existe une bibliothèque, vous pouvez utiliser l'autre langue, alors ne vous embêtez pas avec C/C++. Je ne le fais de nos jours que lorsque je cible des systèmes embarqués qui ne peuvent pas (facilement?) Exécuter des langues. Parfois j'utilise C parce que j'écris un plugin mais vraiment non.
Cependant, je n'utiliserais pas Python, Perl, etc. pour éviter d'utiliser C. Ma préférence est en fait C #, car j'aime une bonne bibliothèque (qui est une force de .NET), et j'aime les langages typés statiquement. Boo est une bonne alternative. Mais vraiment Haskell , OCaml , D , ML et tout va bien.
Il y a en fait une réponse unique à toutes les questions formulées comme ceci. La meilleure raison d'utiliser la technologie X au lieu de la technologie Y (où X et Y sont à peu près au même niveau [comme à peu près tous les langages de programmation contemporains le sont]) est parce que vous connaissez déjà X et ne connaissez pas Y.
(mais après l'arrivée de Haskell, il n'y avait aucune raison d'utiliser autre chose)