Quel langage de programmation génère le moins de bogues difficiles à trouver? [fermé]

54

Quelle langue, à votre avis, permet au programmeur moyen de générer des fonctionnalités avec le moins de bogues difficiles à trouver? Il s’agit bien entendu d’une question très vaste, et j’intéresse des réponses et des idées très larges et générales.

Personnellement, je trouve que je passe très peu de temps à rechercher des bogues étranges dans les programmes Java et C #, alors que le code C ++ a son ensemble distinct de bogues récurrents, et que Python / similar possède son propre ensemble de bogues communs et stupides qui seraient détectés par le compilateur. dans d'autres langues.

De plus, j'ai du mal à envisager les langages fonctionnels à cet égard, car je n'ai jamais vu un programme volumineux et complexe écrit en code entièrement fonctionnel. Votre entrée s'il vous plaît.

Éditer: Clarification complètement arbitraire d'un bogue difficile à trouver: Il faut plus de 15 minutes pour reproduire ou plus d'une heure pour trouver la cause et la correction.

Pardonnez-moi s'il s'agit d'un doublon, mais je n'ai rien trouvé sur ce sujet spécifique.

— Magnus Wolffelt
source

10

J'aimerais que des recherches soient effectuées sur ce sujet! Non seulement "mes preuves anecdotiques suggèrent que le seul langage que je connaisse est roi", mais les taux de bugs de grands projets, etc.

— Frank Shearar,

@Frank .. si vous aviez BEAUCOUP (et je veux dire BEAUCOUP) de temps, vous pourriez probablement extraire certaines statistiques de ohloh, à condition que vous puissiez identifier les correctifs qui corrigent des bogues dans des milliers de référentiels de code.

— Tim Post

Celui où seuls les commentaires sont autorisés. Pas d'autres instructions :)

— Victor Hurdugaci

4

Je pense que "difficile à trouver" doit être clarifié. Votre question et la plupart des réponses semblent définir "difficile à trouver" comme étant équivalent à "non capturé par le compilateur". Vous mentionnez python comme ayant des bugs stupides qui seraient détectés par le compilateur. C'est suffisant. Mais ces bugs stupides ne sont généralement pas difficiles à trouver. Certes, ils ne font pas partie de la même catégorie que les bogues C ++ dérivés de la libération de mémoire, par exemple, trop tôt.

— Winston Ewert

@ Winston D'accord.

— Magnus Wolffelt

58

Plus le système de types du langage est puissant, plus nombreux seront les bogues détectés au moment de la compilation.

La figure suivante compare certains des langages de programmation bien connus en termes de puissance, de simplicité et de sécurité de leurs systèmes types. [ Source ]

texte alternatif

* Prise en compte de la capacité à utiliser des constructions non sécurisées.

C # est bloqué dans la ligne non sécurisée à cause du mot clé "unsafe" et du mécanisme de pointeur associé. Mais si vous souhaitez les considérer comme une sorte de mécanisme de fonction étrangère intégré, n'hésitez pas à déplacer C # vers le ciel.

J'ai marqué Haskell '98 comme pur mais GHC Haskell comme non pur en raison de la famille de fonctions non sécurisées *. Si vous désactivez unsafe *, passez à GHC Haskell.

— manquants
source

8

C'est génial!

7

Je n'ai pas trouvé de Common Lisp dans le graphique: (let ((itbe '())) ... )...

— duros

7

Quelle? Il n'y avait plus d'espace libre sur le côté gauche pour PHP?

— Pestaa

7

C # autorise les pointeurs sûrs : toutes les arithmétiques de pointeurs sont vérifiées. Par conséquent, je pense que cela devrait être le cas avec Java.

— Alex ten Brink

11

@missingfaktor: Je pense que C # n'est pas bien placé. C # permet et promeut les styles de programmation safter. Cela ne devrait pas être mesuré par la pire chose que cela permet.

— back2dos

20

À mon avis, Haskell vous aide à éviter certaines sources d'erreur communes:

c'est purement fonctionnel: les fonctions ne peuvent pas avoir d'effets secondaires (involontaires) ce qui rend la programmation multicœur plus facile et moins sujette aux erreurs
il est fortement typé: vous ne pouvez par exemple pas mélanger accidentellement les valeurs bool, char, int et float
il est typé statiquement: de nombreuses erreurs de programmation sont interceptées au moment de la compilation
nullne fait pas partie des définitions de type de valeur: vous évitez ainsi l' erreur d'un milliard de dollars
Il existe de nombreuses fonctions prédéfinies d'ordre supérieur que vous pouvez réutiliser au lieu d'écrire vos propres implémentations, éventuellement défectueuses.
il dispose d'un ramasse-miettes: les erreurs de mémoire sont presque éliminées (à l'exception des "fuites d'espace" en raison de sa stratégie d'évaluation paresseuse)

— LennyProgrammers
source

11

Je ne vais pas baisser la note, mais je suis tenté de le faire, car cela ne correspond pas aux critères. Il est supposé permettre à "le programmeur moyen de générer des fonctionnalités" avec un nombre minimal de bogues, mais le programmeur moyen, pour le dire franchement, ne peut pas faire la tête ou la queue de Haskell en premier lieu.

— Mason Wheeler

5

Beaucoup de bons points, mais en supprimant certaines classes d'erreur (effets secondaires inattendus, conversions de type inattendues), Haskell ajoute une toute nouvelle classe d'erreur: les fuites d'espace. (De plus, même s'il n'y en a pas null, il y undefineden a un qui est un membre de tous les types.)

— j_random_hacker

5

@Mason: Si vous n'y écrivez pas, vous ne pouvez pas avoir de bogues int :) :)

— Michael K

2

Je suppose qu'il n'y a pas de repas gratuit - vous pouvez avoir des bogues faciles à trouver, ou du code facile à écrire, mais pas les deux :)

— Benjol

6

@Mason Qu'est-ce qu'un «programmeur moyen»? La question commence par «quel langage de programmation ...», pas «qui parmi C, C ++ et Java ...»;)

— Agos

18

Les bogues les plus difficiles à trouver sont généralement les conditions de concurrence dans les applications multithreads,

presque impossible à reproduire
peut être très subtile

Par conséquent, vous avez besoin de langues qui gèrent le parallélisme pour vous le plus possible et le moins intrusif possible. Ce ne sont pas encore grand public. Java en fait, mais vous laisse avec la partie difficile.

À ma connaissance, vous avez besoin d'un langage fonctionnel, car "l'absence d'effets secondaires" est la chose qui fait en premier lieu la disparition des deux points. J'ai constaté que le travail est en cours pour faire de Haskell un langage multi-thread efficace et transparent, et je pense que Fortress est conçu dès le départ pour être un langage parallèle efficace.

Edit: En Java, Executorsmanipulez encore plus de parties difficiles. Vous devez adapter les tâches individuelles à l' Callableinterface.

— utilisateur1249
source

5

++ Conditions de course. Tu peux le répéter.

— Mike Dunlavey

Ouais. N'oubliez pas que l'informatique parallèle en général est difficile, même avec l'assistance linguistique. (Les macros Common Lisp sont difficiles, malgré beaucoup de prise en charge de la langue, car leur travail est très puissant. Même principe.)

— David Thornley

Qu'en est-il d'Erlang?

— Malfist

@ Malfist, je ne connais pas suffisamment Erlang pour répondre à cette question. Peut-être devriez-vous ouvrir une question si vous voulez vraiment savoir?

2

Erlang est une programmation fonctionnelle conçue pour rendre le multithreading simple et sûr. Vous ne partagez pas les variables, vous transmettez des messages. Lire c'est la page wikipedia.

— Malfist

13

Ada est conçu pour que le plus grand nombre possible soit capturé au moment de la compilation plutôt qu'au moment de l'exécution. Cela signifie qu'il faut souvent environ 10 fois plus de temps pour compiler un programme dans Ada que son équivalent en Java, mais quand il compile, vous pouvez être beaucoup plus sûr que des classes entières de bogues ne se manifesteront pas lorsque le programme courir.

— Mark Pim
source

7

+1 pour avoir remarqué, correctement, qu'Ada attrape dans le compilateur des choses que les autres langues ignorent. -1 pour l'affirmation que cela signifie qu'il faut 10 fois plus de temps pour qu'un programme Ada soit compilé. Ada récompense le programmeur qui conçoit !!! son code, qui pense !!! à propos de ce qu'il fait avant qu'il commence à taper follement. Mon expérience personnelle dans la programmation de production dans Ada pour le travail de défense a été qu’il n’a pas fallu beaucoup plus de temps pour compiler le code Ada qu’en C / C ++ ou en FORTRAN, mais le code Ada rencontrait beaucoup moins de problèmes plus tard. Pratt & Whitney a remarqué quelque chose de similaire.

— John R. Strohm

1

@john r strohm, d'après ce que j'ai compris, il ne parle pas du temps nécessaire au compilateur pour compiler le code, mais plutôt du temps nécessaire pour rendre le code compilable.

— Malfist

Oh d'accord pour obtenir le code compilable. Je me souviens de pas mal de commentaires sexistes de programmeurs apprenant la langue à propos de son choix. Eh bien, si vous nommez une langue comme une femme ...

— Michael Shaw

@Ptolemy, si les bateaux peuvent être nommés d'après des femmes (sauf apparemment pour les transporteurs américains), les langages de programmation le peuvent aussi. Faites-le plutôt nommer "Ada" que "USS Ronald Reagan" :)

1

Une fois ma courbe d'apprentissage terminée, j'ai rapidement écrit le code Ada, après avoir passé beaucoup de temps à réfléchir à la conception. Ada n'est certainement pas la langue d'un hacker. De nos jours, je travaille à Java et certaines des choses que je vois dans mes projets en cours me font un peu manquer à Ada (je n'aurais jamais pensé dire ça).

— James Adam

7

Tout d’abord une définition: un bogue difficile à trouver, si je comprends bien, est un bogue qui peut être reproduit mais dont la cause est difficile à trouver.

L'aspect le plus important est probablement ce que j'appellerais l' étroitesse , c'est-à-dire jusqu'où un bogue peut-il échapper, quelle est la portée d'un bogue pouvant potentiellement influencer. Dans des langages tels que C, un bogue, par exemple un index de tableau négatif ou un pointeur non initialisé, peut affecter littéralement tout le contenu du programme. Dans le pire des cas, vous devez tout vérifier partout pour trouver la source de votre problème.

Les bonnes langues à cet égard prennent en charge les modificateurs d'accès et les appliquent de manière à rendre difficile, voire impossible, de les contourner. Les bons langages vous encouragent à limiter la portée de vos variables au lieu de rendre trop facile l’utilisation de variables globales (par exemple, "tout ce qui n’est pas explicitement déclaré est une variable globale avec un type et une valeur par défaut").

Le deuxième aspect important est la concurrence . Les conditions de course sont généralement difficiles à reproduire et donc difficiles à trouver. Les bonnes langues offrent des mécanismes de synchronisation faciles à utiliser et leurs bibliothèques standard sont thread-safe si nécessaire.

Cela complète déjà ma liste; D'autres choses, comme la frappe forte, aident à attraper les bogues au moment de la compilation, mais ces bogues ne seront probablement pas difficiles à trouver plus tard.

Compte tenu de tout cela, je dirais que Java et C #, ainsi que de nombreux autres langages dans le monde de la JVM et du .net, sont appropriés pour éviter les bogues difficiles à trouver.

— utilisateur281377
source

Le verrouillage manuel peut sembler être un "mécanisme de synchronisation facile à utiliser", mais il n’est vraiment que "simple à utiliser, mais vous êtes prêt à vous amuser pendant que vous cherchez à sortir de cette impasse". Et bien, vous pouvez faire une concurrence basée sur Actor dans plusieurs langues.

— Frank Shearar

Frank: au moins, verrouiller est assez simple pour que tout le monde puisse le faire sans passer des jours à déterminer quelle API utiliser, etc.

— user281377

Ensuite, il y a le point de vue selon lequel une solution d'accès simultané qui est "assez simple pour que tout le monde puisse le faire" revient à donner des scies à table aux enfants d'âge préscolaire.

— David Thornley

@ David: Je comprends votre point de vue, mais dans de nombreux cas, une solution simple est vraiment tout ce qu'il faut. Par exemple, considérons un servlet utilisé par une poignée d'utilisateurs, qui doit utiliser une ressource partagée (par exemple, la connexion à la base de données). Sans synchronisation, les conditions de course se produisent de temps en temps; mais ce n'est pas tout à fait sorcier de placer toutes les opérations d'accès à la base de données dans un bloc synchronisé (connexion) {}.

— user281377

+1 Pour cette définition, "quelle est l'étendue qu'un bogue peut potentiellement influencer". J'avais quelques bugs très méchants avec les langages dynamiques où un objet du type de données incorrect était allé très loin dans le code (grâce à la frappe de canard) avant de se manifester en tant que bogue.

— Giorgio

7

Comme Excel est le DSL le plus utilisé, je choisirai Excel. (hors VBA bien sûr)

Cela correspond à la facture:

C'est toujours facile à reproduire (voici un tableur, ça ne marche pas)
Il est assez facile de trouver le bogue, car il est totalement "fonctionnel" - commencez par la cellule qui est fausse et tracez toutes ses dépendances.

— Scott Whitlock
source

Cela pourrait être vrai tant que vous n'ajoutez pas de bogues faciles à trouver.

— mouviciel

+1 Un peu effronté puisque Excel est une donnée, pas une langue. M'a donné un bon rire :)

— récursion.ninja

2

@awashburn - oh, je ne sais pas. Je pense que cela est considéré comme une langue. Chaque cellule est une "variable". De manière déclarative, chaque variable est définie comme un littéral (tel que 123ou ABC) ou une fonction ( =SUM(A2:A5)). Excel évalue ensuite toutes les variables, déterminant l'ordre dans lequel résoudre les dépendances, etc. Il ne s'agit certainement pas que de données.

— Scott Whitlock

2

Je retire ma déclaration, il s'avère qu'Excel est Turing Complete ... J'ai appris quelque chose de complètement déroutant ...

— récursion.ninja

1

"... le vrai maître [Lisp] réalise que toutes les données sont du code." Peut-être cela s'applique-t-il également à Excel, assez tôt. blogs.msdn.com/b/sriram/archive/2006/01/15/lisp-is-sin.aspx

— James Mishra

7

C'est une question difficile, car la plupart des bogues ne sont pas la faute du langage lui-même, mais plutôt la faute des développeurs qui font des erreurs dans leur utilisation du langage.

Je pense que plusieurs aspects des fonctionnalités du langage affectent la probabilité de bugs:

Interactivité - les langages dynamiques avec REPL encouragent l'interaction / l'expérimentation avec des programmes en cours d'exécution et des cycles de code / tests beaucoup plus petits. Si vous pensez que l'itération est un bon moyen de découvrir des solutions simples et propres et de détecter / éliminer les bogues, cela favoriserait les langages interactifs.
Expressivité - Si le code est plus court et moins complexe, il est alors plus facile de détecter les bogues / les erreurs de logique.
Sécurité des types - plus le temps de compilation est long, plus le nombre de bogues détectés sera élevé, donc la sécurité des types est une bonne chose. Cependant, ils ne sont généralement pas difficiles à trouver - même dans un langage totalement dynamique, un type incorrect dans une structure de données provoquera généralement une erreur d'exécution très évidente, et TDD détecte presque toujours ce type de bogues.
Immutabilité - beaucoup de bugs durs sont dus à des interactions complexes entre des états mutables. Les langues qui mettent l’accent sur l’immutabilité (Haskell, Clojure, Erlang) ont un énorme avantage en évitant la mutabilité
Programmation fonctionnelle - les approches fonctionnelles pour écrire du code tendent à être plus "prouvées correctes" que le code orienté objet avec des séquences complexes d’effets / interactions. Mon expérience est que la PF aide à éviter les bugs difficiles - je crois qu'il y a des recherches universitaires quelque part que je ne trouve pas actuellement qui corroborent cela.
Prise en charge des accès simultanés - les problèmes d’accès simultané sont particulièrement difficiles à détecter et à déboguer, raison pour laquelle c’est si important. Tout ce qui nécessite un verrouillage manuel est finalement voué à l'échec (et cela inclut à peu près toutes les approches orientées objet de la simultanéité). Le meilleur langage que je connaisse à cet égard est Clojure - il a une approche unique en matière de gestion de la simultanéité qui associe une mémoire transactionnelle logicielle à des structures de données immuables pour obtenir un nouveau cadre de concurrence simultanée fiable et composable. Voir http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey pour plus d'informations.

— mikera
source

Les gens comme moi qui sont des partisans passionnés de la programmation fonctionnelle apprécient cette réponse. L'expressivité est votre ami.

— Sridhar Sarnobat

1

Meilleure réponse jusqu'à présent! Je pense que cela est corroboré par les deux analyses suivantes de la fréquence des bogues: délibérer - software.com / safety - rank-part-2 et macbeth.cs.ucdavis.edu/lang_study.pdf . Ils montrent tous les deux que plus la langue est pure, fonctionnelle, expressive et sûre, moins elle a de bogue. De même, ils montrent tous deux que Clojure et Ruby échappent à la règle de sécurité, indiquant probablement que l'interactivité a un impact égal à celui que vous avez indiqué.

— Didier A.

@ DidierA. malheureusement, le lien ucdavis est cassé (sans archive wbm) - je pense que vous l'avez obtenu de la page de Prem Devanbu qui pointe maintenant vers un lien mis à jour: Une étude à grande échelle des langages de programmation et de la qualité du code dans Github

— icc97

5

Moins une langue est puissante, moins elle vous donne le choix de tirer votre propre pied.

Les langages de haut niveau tels que Java et C # produiront moins de bogues que les langages de bas niveau tels que C ++.

Cela dit, j’estime que Java est plus sécurisé que C #. Java est limité artificiellement afin qu'un programmeur moyen sans connaissances avancées puisse le maîtriser et produire des programmes stables.

— utilisateur8685
source

4

+1 pour "Moins une langue est puissante, moins elle vous donne le choix de tirer votre propre pied."

— Michael K

Le graphique de missingfaktor semble indiquer que C # et C ++ sont sur un pied d'égalité, dans la mesure où ils sont capables de se prendre en photo, il élève Java au-dessus de cela. Non pas que je sois d’accord avec cette partie du graphique. Vous êtes obligé de passer à travers des cerceaux pour faire de la prise de vue en C #.

— Jesse C. Slicer

6

La sécurité et le pouvoir ne sont pas inversement proportionnels (c'est ce que vous semblez penser ;-) Haskell, par exemple, est extrêmement puissant et dispose de très peu de moyens pour se tirer une balle dans le pied.

— missingfaktor

3

Si la langue est faible, vous avez juste besoin d'un pied plus grand.

7

@missingfaktor, c'est parce que c'est un effet secondaire de se tirer une balle dans le pied.

3

Quelle langue, à votre avis, permet au programmeur moyen de générer des fonctionnalités avec le moins de bogues difficiles à trouver?

À mon avis, Delphi. Basé sur le langage Pascal, le langage est assez simple et intuitif pour que le programmeur moyen (ou même les codeurs inexpérimentés) le découvre facilement. Son support riche en outils et en bibliothèques facilite la recherche de la plupart des bogues.

Une frappe forte et un compilateur strict qui corrige de nombreuses erreurs courantes.
Syntaxe intuitive qui n'encourage pas les erreurs courantes. ("Le dernier bogue du monde" if (alert = RED) {LaunchNukes;}ne sera pas compilé, par exemple.)
Un modèle objet bien conçu qui élimine la plupart des erreurs de programmation orientées objet C ++ courantes.
Vérification des limites et vérification des plages intégrée à la langue, réduisant considérablement les risques de problèmes de sécurité.
Probablement le compilateur le plus rapide que l’on connaisse, ce qui augmente votre productivité et rend plus difficile la perte de vos idées en attendant une construction.
Le débogueur du débogueur de Visual Studio veut être comme quand il grandit.
Le suivi des fuites est directement intégré au gestionnaire de mémoire, ce qui rend la recherche et la correction des fuites de mémoire triviales.
Une grande bibliothèque standard mature offrant des moyens prédéfinis et pré-testés d’accomplir des tâches courantes sans avoir à créer vos propres implémentations, éventuellement boguées.
Livré avec des outils utiles, tels qu'un système de journalisation puissant et un profileur, pour faciliter le suivi des problèmes.
Prise en charge solide de la communauté pour les problèmes courants qui ne figurent pas dans la bibliothèque standard, y compris une puissante bibliothèque tierce concurrente .

— Mason Wheeler
source

Je suis un jockey de Delphes depuis longtemps, mais il s'est éloigné de ses racines Pascal quand il m'a permis de transtyper n'importe quoi d'autre, à la C / C ++:var I: Integer; Pointer(I)^ := $00;

— Jesse C. Slicer

1

@ Jesse: Peut-être, mais je vois cela comme une concession nécessaire au pragmatisme. Kernighan a fait beaucoup de points positifs lorsqu'il a écrit Why Pascal n'est pas mon langage de programmation préféré. Les transmissions de type sont nécessaires pour accomplir beaucoup de choses importantes de bas niveau. Mais l’un des points forts de Delphi réside dans la manière dont ses bibliothèques encapsulent les détails de bas niveau et rendent inutiles la plupart des éléments non sécurisés de pointeur et de transtypage.

— Mason Wheeler

Je ne suis pas en désaccord sur le fait que cela peut être nécessaire - mais affirmer que le typage fort est quelque peu contredit par cela. Pascal original n'autorisait pas de telles manigances et était donc fortement typé. Mais je n’irais pas aussi loin pour dire que Delphi est faiblement dactylographié - c’est en quelque sorte «moyennement typé».

— Jesse C. Slicer

1

@ Jesse: La version originale de Wirth de Pascal n'a-t-elle pas autorisé les enregistrements de variantes? Ils ont finalement été tellement habitués à subvertir la dactylographie avec force que Borland et d’autres ont décidé de ne mettre que des typecasts pour simplifier les choses car tout le monde le faisait.

— Mason Wheeler

en.wikipedia.org/wiki/Pascal_(programming_language ) #Divisions et en.wikipedia.org/wiki/Pascal_(programming_language)#Criticism ainsi que pascal-central.com/ppl/chapter3.html semblent indiquer qu'il en faisait partie la première norme en 1983. Je vois certaines références de Wirth qui semblent dater de 1974, alors je dirais que oui. Je pense que la partie problématique permettait de le subvertir en tant que tel (les champs variants prenant la même mémoire, comme les unions en C). S'ils étaient simplement utilisés comme un mécanisme de cadrage et que la disposition de la mémoire était destinée au sur-ensemble, elle serait plus puissante.

— Jesse C. Slicer

2

Une chose à prendre en compte est le délai d'exécution.

Au cours des cinq dernières années environ, j'ai principalement développé des applications Web en Java (JSF, Seam, etc.). Récemment, j'ai eu un nouvel emploi et nous utilisons Perl (avec Catalyst et Moose).

Je suis beaucoup plus productif en Perl qu'en Java.

Ne pas avoir besoin de compiler et de déployer (à chaud), en est une des raisons. Je trouve également que l'écriture de cas d'utilisation est plus facile, car cela peut être fait de manière plus itérative. Et les frameworks en Java semblent être un complexe inutile, au moins pour les projets dans lesquels j'ai été impliqué.

Je suppose que le nombre de bogues dans mon code Perl est plus ou moins le même que le nombre de bogues dans mon code Java, il pourrait même être plus élevé. Mais, je trouve et plus facile et plus rapide de trouver et de corriger ces bugs.

— slu
source

1

Peut-être qu'une analyse du nombre d'outils disponibles pour l'analyse de code statique et dynamique pour chaque langage de programmation pourrait donner une idée. Plus il y a d'outils pour une langue, plus il est probable que la langue soit très populaire parmi les utilisateurs ou très populaire pour générer des bogues difficiles à trouver. Mais je ne parviens pas à me faire indiquer par Google aucune étude réalisée à ce sujet. Il convient également de noter que certaines langues telles que le langage C peuvent être utilisées pour contourner les bogues matériels sous-jacents, ainsi que pour éviter l'usure du matériel à mesure qu'il vieillit.

— vpit3833
source

1

"contourner l'usure du matériel à mesure qu'il vieillit" ...?

— j_random_hacker

J'ai lu que certains systèmes d'exploitation Unix fonctionnant sur des machines critiques contrôlent l'intégrité du processeur, de la RAM et de tout autre matériel. serverfault.com/questions/56192/… en parle plus en détail. Si certaines lignes d'un module de mémoire vive deviennent défectueuses au fil du temps, ces modules ne seront pas utilisés par le système d'exploitation et ne seront pas signalés dans la mémoire physique totale disponible. De telles choses pourraient également être faites sur d'autres matériels.

— vpit3833

C'est une friandise intéressante, mais je ne vois pas en quoi elle est pertinente ici. De plus, rien dans votre lien ne mentionne ces systèmes d’exploitation Unix auto-réparateurs - il ne fait que parler des moyens de soumettre à un stress le matériel d’un PC.

— j_random_hacker

1

Je l'ai mentionné comme signifiant que les programmes seuls pourraient ne pas être à l'origine des bogues, mais aussi du matériel ou d'autres facteurs externes.

— vpit3833

1

Au lieu de parler de langues, qu'en est-il de parler de fonctionnalités linguistiques?

Java vous oblige à penser aux exceptions (jets ...) et vous devez soit publier, soit gérer ces exceptions. Est-ce que cela m'empêche vraiment d'oublier les erreurs de localisation ou est-ce que j'utilise davantage d'exceptions dérivées de SystemException qui n'ont pas besoin de ce traitement?
Qu'en est-il de "conception par contrat" (http://en.wikipedia.org/wiki/Design_by_contract) qui me force à penser aux conditions préalables et ultérieures. J'ai lu que c'est maintenant possible avec c # -4.0.

— k3b
source