Welche Programmiersprache erzeugt die wenigsten schwer zu findenden Fehler? [geschlossen]

54

Mit welcher Sprache kann der durchschnittliche Programmierer Ihrer Meinung nach Funktionen mit der geringsten Anzahl schwer zu findender Fehler ausgeben? Dies ist natürlich eine sehr breite Frage, und ich interessiere mich für sehr breite und allgemeine Antworten und Weisheiten.

Persönlich verbringe ich sehr wenig Zeit damit, nach seltsamen Fehlern in Java- und C # -Programmen zu suchen, während C ++ - Code einen eigenen Satz von wiederkehrenden Fehlern aufweist und Python / similar einen eigenen Satz von allgemeinen und albernen Fehlern aufweist, die vom Compiler erkannt würden in anderen Sprachen.

Außerdem fällt es mir schwer, funktionale Sprachen in dieser Hinsicht zu berücksichtigen, da ich noch nie ein großes und komplexes Programm gesehen habe, das in vollständig funktionalem Code geschrieben ist. Ihre Eingabe bitte.

Bearbeiten: Vollständig willkürliche Klärung schwer auffindbarer Fehler: Die Reproduktion dauert mehr als 15 Minuten, und die Suche nach Ursachen und deren Behebung dauert mehr als 1 Stunde.

Verzeihen Sie mir, wenn dies ein Duplikat ist, aber ich habe zu diesem bestimmten Thema nichts gefunden.

— Magnus Wolffelt
quelle

10

Ich würde gerne Nachforschungen zu diesem Thema anstellen! Nicht nur "meine anekdotischen Beweise deuten darauf hin, dass die einzige Sprache, die ich kenne, König ist", sondern auch Fehlerquoten bei großen Projekten und so weiter.

— Frank Shearar

@Frank .. Wenn Sie eine Menge Zeit (und ich meine eine Menge) hatten, könnten Sie wahrscheinlich einige Statistiken aus Ohloh abrufen, vorausgesetzt, Sie könnten Patches identifizieren, die Fehler aus Tausenden von Code-Repositories behoben haben.

— Tim Post

Derjenige, wo nur Kommentare erlaubt sind. Keine weiteren Anweisungen :)

— Victor Hurdugaci

4

Ich denke, "schwer zu finden" muss geklärt werden. Ihre Frage und die meisten Antworten scheinen "schwer zu finden" als "nicht vom Compiler abgefangen" zu definieren. Sie erwähnen Python als albern Fehler, die vom Compiler erkannt würden. Fair genug. Aber diese dummen Käfer sind normalerweise nicht so schwer zu finden. Sicherlich sind sie nicht in der gleichen Kategorie wie C ++ - Fehler, die durch zu frühes Freigeben von Speicher entstehen.

— Winston Ewert

@ Winston Zustimmen.

— Magnus Wolffelt

58

Je leistungsfähiger das Typsystem der Sprache ist, desto mehr Fehler werden zur Kompilierungszeit selbst abgefangen.

Die folgende Abbildung vergleicht einige der bekannten Programmiersprachen hinsichtlich der Leistungsfähigkeit, Einfachheit und Sicherheit ihrer Typsysteme. [ Quelle ]

Alt-Text

* Berücksichtigung der Fähigkeit, unsichere Konstrukte zu verwenden.

C # wird aufgrund des Schlüsselworts "unsafe" und der zugehörigen Zeigermaschine in die unsichere Zeile eingefügt. Wenn Sie sich diese als eine Art Inline-Fremdfunktionsmechanismus vorstellen möchten, können Sie C # nach oben drücken.

Ich habe Haskell '98 als rein eingestuft, aber GHC Haskell aufgrund der unsicheren * Funktionsfamilie als nicht rein eingestuft. Wenn Sie unsicher * deaktivieren, springen Sie GHC Haskell entsprechend nach oben.

— missingfaktor
quelle

8

Das ist brilliant!

7

Ich konnte Common Lisp in der Grafik nicht finden: (let ((itbe '())) ... )...

— Duros

7

Was? Auf der linken Seite war kein Platz mehr für PHP?

— pestaa

7

C # erlaubt sichere Zeiger: Alle Zeigerarithmetik wird geprüft. Daher denke ich, dass es mit Java dort oben sein sollte.

— Alex ten Brink

11

@missingfaktor: Ich denke C # ist nicht gut positioniert. C # erlaubt und fördert Safter-Programmierstile. Es sollte nicht am Schlimmsten gemessen werden, was es erlaubt.

— back2dos

20

Meiner Meinung nach hilft Ihnen Haskell dabei, einige häufige Fehlerquellen zu vermeiden:

Es ist rein funktional: Funktionen können keine (unbeabsichtigten) Nebenwirkungen haben und das macht die Multicore-Programmierung einfacher und weniger fehleranfällig
Es ist stark typisiert: Sie können zB nicht versehentlich Bool-, Char-, Int- und Float-Werte mischen
Es ist statisch typisiert: Viele Programmierfehler werden beim Kompilieren abgefangen
nullgehört nicht zu den Werttypdefinitionen: Auf diese Weise vermeiden Sie den Milliarden-Dollar-Fehler
Es gibt viele vorgefertigte Funktionen höherer Ordnung, die Sie wiederverwenden können, anstatt Ihre eigenen, möglicherweise fehlerhaften Implementierungen zu schreiben
es hat einen Garbage Collector: Speicherfehler werden fast beseitigt (mit Ausnahme von "Space Leaks" aufgrund seiner verzögerten Auswertungsstrategie)

— LennyProgrammers
quelle

11

Ich werde das nicht ablehnen, aber ich bin versucht es zu tun, weil es nicht den Kriterien entspricht. Es soll "dem durchschnittlichen Programmierer ermöglichen, Funktionen mit einer minimalen Fehleranzahl auszugeben", aber der durchschnittliche Programmierer kann, um es klar auszudrücken, Haskell überhaupt nicht in den Schatten stellen.

— Mason Wheeler

5

Viele gute Punkte, aber beim Entfernen einiger Fehlerklassen (unbeabsichtigte Nebenwirkungen, unerwartete Typkonvertierungen) fügt Haskell eine ganz neue Fehlerklasse hinzu: Space Leaks. (Auch wenn es keine nullgibt, gibt es undefined, die ein Mitglied jeder Art ist.)

— j_random_hacker

5

@Mason: Wenn Sie nicht darin schreiben, können Sie keine Bugs darin haben :)

— Michael K

2

Ich denke, es gibt kein kostenloses Mittagessen - Sie können leicht zu findende Fehler oder einfach zu schreibenden Code haben, aber nicht beide :)

— Benjol

6

@Mason was genau ist ein "durchschnittlicher Programmierer"? Die Frage beginnt mit "welche Programmiersprache ...", nicht "welche unter C, C ++ und Java ...";)

— Agos

18

Die am schwersten zu findenden Fehler sind traditionell die Race-Bedingungen in Multithread-Anwendungen

fast unmöglich zu reproduzieren
kann sehr subtil sein

Daher brauchen Sie Sprachen, die den Parallismus für Sie so weit und unauffällig wie möglich beherrschen. Diese sind noch nicht Mainstream. Java erledigt einige Aufgaben, überlässt Ihnen jedoch den schwierigen Teil.

Meines Erachtens brauchen Sie eine funktionierende Sprache, da "keine Nebenwirkungen" die beiden Aufzählungspunkte erst einmal verschwinden lassen. Ich habe gesehen, dass die Arbeit daran, Haskell zu einer effizienten Multithread-Sprache zu machen, fortgesetzt wird, und ich glaube, dass Fortress von Grund auf als effiziente Parallelsprache konzipiert wurde.

Bearbeiten: In Java Executorsbehandeln noch mehr der harten Teile. Sie müssen die einzelnen Aufgaben an die CallableBenutzeroberfläche anpassen .

— user1249
quelle

5

++ Rennbedingungen. Können Sie laut sagen.

— Mike Dunlavey

Ja. Bedenken Sie, dass paralleles Rechnen im Allgemeinen selbst mit Sprachunterstützung schwierig ist. (Gemeinsame Lisp-Makros sind trotz viel Sprachunterstützung schwierig, da sie sehr leistungsfähig sind. Dasselbe Prinzip.)

— David Thornley

Was ist mit Erlang?

— Malfist

@Malfist, ich weiß nicht genug über Erlang, um das zu beantworten. Vielleicht sollten Sie eine Frage öffnen, wenn Sie es wirklich wissen wollen?

2

Erlang ist eine funktionale Programmierung, die Multithreading einfach und sicher macht. Sie teilen keine Variablen, Sie übergeben Nachrichten. Lesen Sie die Wikipedia-Seite.

— Malfist

13

Ada ist so konzipiert, dass möglichst viel zur Kompilierungszeit und nicht zur Laufzeit abgefangen wird. Dies bedeutet, dass das Kompilieren eines Programms in Ada oft etwa 10-mal länger dauert als in Java, aber wenn es kompiliert wird, können Sie sicherer sein, dass sich ganze Klassen von Fehlern nicht manifestieren, wenn das Programm ausgeführt wird Lauf.

— Mark Pim
quelle

7

+1 für das richtige Erkennen, dass Ada Dinge im Compiler abfängt, die andere Sprachen ignorieren. -1 für die Behauptung, dass dies bedeutet, dass es 10x länger dauert, bis ein Ada-Programm kompiliert ist. Ada belohnt den Programmierer, der DESIGNS !!! sein Code, der denkt !!! über das, was er tut, bevor er wahnsinnig tippt. Meine persönliche Erfahrung mit der Erstellung von Produktionsprogrammen in Ada für Verteidigungszwecke war, dass das Kompilieren von Ada-Code nicht wesentlich länger dauerte als C / C ++ oder FORTRAN, aber der Ada-Code hatte später erheblich weniger Probleme. Pratt & Whitney bemerkten etwas Ähnliches.

— John R. Strohm

1

@john r strohm, soweit ich weiß, spricht er nicht von der Zeit, die der Compiler benötigt, um Code zu kompilieren, sondern von der Zeit, um den Code kompilierbar zu machen.

— Malfist

oh war einverstanden damit, den Code kompilierbar zu machen. Ich kann mich an eine Menge sexistischer Kommentare erinnern, die von Programmierern gemacht wurden, die die Sprache über das Nit-Picking lernten. Normalerweise nach dem Vorbild von Well, wenn Sie eine Sprache nach einer Frau benennen ...

— Michael Shaw

@Ptolemy, wenn Boote nach Frauen benannt werden können (außer anscheinend für US-amerikanische Fluggesellschaften), können auch Programmiersprachen verwendet werden.

1

Sobald ich die Lernkurve hinter mir hatte, konnte ich Ada-Code ziemlich schnell schreiben - nachdem ich viel Zeit damit verbracht hatte, das Design zu durchdenken. Ada ist definitiv keine Hackersprache. Ich arbeite heutzutage in Java und einige Dinge, die ich in meinen aktuellen Projekten sehe, lassen mich Ada ein wenig vermissen (hätte ich nie gedacht, dass ich das sagen würde).

— James Adam

7

Zunächst eine Definition: Ein schwer zu findender Fehler ist, wie ich es verstehe, ein Fehler, der reproduziert werden kann, dessen Ursache jedoch schwer zu finden ist.

Der wahrscheinlich wichtigste Aspekt ist das, was ich Enge nennen würde , dh wie weit kann ein Fehler entkommen, wie groß ist der Umfang, den ein Fehler möglicherweise beeinflussen kann. In Sprachen wie C kann ein Fehler, z. B. ein negativer Array-Index oder ein nicht initialisierter Zeiger, buchstäblich alles im gesamten Programm betreffen. Im schlimmsten Fall müssen Sie also überall nach der Ursache des Problems suchen.

Gute Sprachen in dieser Hinsicht unterstützen Zugriffsmodifikatoren und erzwingen sie auf eine Weise, die es schwierig oder unmöglich macht, sie zu umgehen. Gute Sprachen ermutigen Sie, den Umfang Ihrer Variablen einzuschränken, anstatt es zu einfach zu machen, globale Variablen zu haben (z. B. "alles, was nicht explizit deklariert wird, ist eine globale Variable mit einem Standardtyp und -wert").

Der zweite wichtige Aspekt ist die Parallelität . Die Rennbedingungen sind im Allgemeinen schwer zu reproduzieren und daher schwer zu finden. Gute Sprachen bieten benutzerfreundliche Synchronisationsmechanismen, und ihre Standardbibliotheken sind bei Bedarf threadsicher.

Dies vervollständigt bereits meine Liste; andere Dinge wie das starke Tippen helfen dabei, Fehler beim Kompilieren zu finden, aber diese Fehler wären wahrscheinlich später nicht schwer zu finden.

In Anbetracht dessen würde ich sagen, dass Java und C # sowie viele andere Sprachen in der JVM- und .net-Welt geeignet sind, um schwer zu findende Fehler zu vermeiden.

— user281377
quelle

Das manuelle Sperren scheint ein "benutzerfreundlicher Synchronisationsmechanismus" zu sein, aber es ist wirklich nur "einfach zu bedienen, aber Sie haben Spaß daran, diesen Deadlock aufzuspüren". Nun, Sie können Actor-basierte Parallelität in mehreren Sprachen durchführen.

— Frank Shearar

Frank: Zumindest ist das Sperren so einfach, dass jeder es tun kann, ohne Tage damit zu verbringen, herauszufinden, welche API zu verwenden ist usw.

— user281377

Dann gibt es den Standpunkt, dass eine Nebenläufigkeitslösung, die "einfach genug ist, damit jeder es tun kann", dem Geben von Tischsägen an Vorschulkinder gleicht.

— David Thornley

@ David: Ich verstehe Ihren Standpunkt, aber in vielen Fällen ist eine einfache Lösung wirklich alles, was es braucht. Stellen Sie sich beispielsweise ein Servlet vor, das nur von wenigen Benutzern verwendet wird und eine gemeinsam genutzte Ressource (z. B. die Datenbankverbindung) verwenden muss. Ohne Synchronisation passieren ab und zu Rennbedingungen. Es ist jedoch keine Hexerei, alle Datenbankzugriffsoperationen in einen synchronisierten (Verbindungs-) {} Block zu setzen.

— user281377

+1 Für diese Definition "Wie groß ist der Bereich, den ein Fehler möglicherweise beeinflussen kann". Ich hatte einige sehr schlimme Fehler mit dynamischen Sprachen, bei denen ein Objekt des falschen Datentyps sehr weit im Code vorkam (dank des Tippens von Enten), bevor es sich als Fehler manifestierte.

— Giorgio,

7

Da Excel das am häufigsten verwendete DSL ist, werde ich mich für Excel entscheiden. (natürlich ohne VBA)

Es passt die Rechnung:

Es ist immer leicht zu reproduzieren (hier ist eine Tabelle - es funktioniert nicht)
Es ist ziemlich einfach, den Fehler zu finden, da er vollständig "funktionsfähig" ist. Beginnen Sie mit der Zelle, die falsch ist, und verfolgen Sie alle Abhängigkeiten.

— Scott Whitlock
quelle

Dies kann zutreffen, solange Sie keine leicht zu findenden Fehler finden.

— Mouviciel

+1 Ein bisschen frech, da Excel keine Sprache, sondern Daten ist. Gab mir ein gutes Lachen :)

— recursion.ninja

2

@awashburn - oh, ich weiß es nicht. Ich denke, es ist eine Sprache. Jede Zelle ist eine "Variable". Jede Variable wird deklarativ entweder als Literal (wie 123oder ABC) oder als Funktion ( =SUM(A2:A5)) festgelegt. Excel wertet dann alle Variablen aus, um herauszufinden, in welcher Reihenfolge Abhängigkeiten gelöst werden sollen usw. Es handelt sich sicherlich nicht nur um Daten.

— Scott Whitlock

2

Ich widerrufe meine Aussage, es stellt sich heraus, dass Excel Turing Complete ist ... Ich habe etwas völlig Beunruhigendes gelernt ...

— recursion.ninja

1

"... der wahre [Lisp] Meister erkennt, dass alle Daten Code sind." Vielleicht trifft dies seltsamerweise auch auf Excel zu. blogs.msdn.com/b/sriram/archive/2006/01/15/lisp-is-sin.aspx

— James Mishra

7

Dies ist eine schwierige Frage, da die meisten Fehler nicht von der Sprache selbst verursacht werden, sondern von Entwicklern, die Fehler bei der Verwendung der Sprache machen.

Ich glaube, es gibt verschiedene Aspekte von Sprachfunktionen, die die Wahrscheinlichkeit von Fehlern beeinflussen:

Interaktivität - Dynamische Sprachen mit REPLs fördern die Interaktion / das Experimentieren mit laufenden Programmen und viel kleineren Code- / Testzyklen. Wenn Sie der Meinung sind, dass Iteration eine gute Möglichkeit ist, saubere und einfache Lösungen zu finden und Fehler zu erkennen / zu beseitigen, ist dies in der Regel für interaktive Sprachen von Vorteil.
Expressivität - Wenn der Code kürzer ist und weniger Boilerplate / zufällige Komplexität aufweist, ist es einfacher, Bugs / Logikfehler zu erkennen.
Typensicherheit - Je mehr Kompilierungszeit überprüft wird, desto mehr Fehler werden vom Compiler abgefangen. Im Allgemeinen ist Typensicherheit also eine gute Sache. Allerdings sind diese Fehler normalerweise nicht schwer zu finden - selbst in einer volldynamischen Sprache führt der falsche Typ in einer Datenstruktur normalerweise zu einem sehr offensichtlichen Laufzeitfehler, und TDD erkennt diese Fehler fast immer.
Unveränderlichkeit - Viele schwere Fehler sind auf komplexe Wechselwirkungen des veränderlichen Zustands zurückzuführen. Sprachen, die Unveränderlichkeit betonen (Haskell, Clojure, Erlang), haben einen enormen Vorteil, indem sie Veränderlichkeit vermeiden
Funktionale Programmierung - funktionale Ansätze zum Schreiben von Code sind in der Regel "beweisbarer" als objektorientierter Code mit komplexen Folgen von Effekten / Interaktionen. Ich habe die Erfahrung gemacht, dass FP dabei hilft, knifflige Fehler zu vermeiden. Ich glaube, dass es irgendwo akademische Forschungen gibt, die ich derzeit nicht finden kann.
Parallelitätsunterstützung - Parallelitätsprobleme sind besonders schwer zu erkennen und zu beheben, weshalb dies so wichtig ist. Alles, was manuelles Sperren erfordert, ist letztendlich zum Scheitern verurteilt (und dies schließt so ziemlich jeden objektorientierten Ansatz zur Parallelität ein). Die beste Sprache, die ich in dieser Hinsicht kenne, ist Clojure - es verfügt über einen einzigartigen Ansatz zum Verwalten der Parallelität, der Software-Transaktionsspeicher mit unveränderlichen Datenstrukturen kombiniert, um ein neues, zuverlässiges und zusammensetzbares Parallelitäts-Framework zu erhalten. Siehe http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey für mehr Einblicke

— mikera
quelle

Leute wie ich, die leidenschaftliche Unterstützer der funktionalen Programmierung sind, schätzen diese Antwort. Ausdruckskraft ist dein Freund.

— Sridhar Sarnobat

1

Beste Antwort bisher! Ich denke, dies wird durch die folgenden zwei Analysen der Fehlerhäufigkeit gestützt: deliberate-software.com/safety-rank-part-2 und macbeth.cs.ucdavis.edu/lang_study.pdf . Sie beide zeigen, dass je reiner, funktioneller, ausdrucksvoller und je sicherer die Sprache ist, desto weniger Fehler hat sie. In ähnlicher Weise zeigen beide, dass Clojure und Ruby sich der Sicherheitsregel entziehen, was wahrscheinlich darauf hinweist, dass Interaktivität die gleichen Auswirkungen hat, wie Sie betont haben.

— Didier A.

@DidierA. Leider ist der ucdavis-Link defekt (ohne WBM-Archiv) - ich glaube, Sie haben ihn von Prem Devanbus Seite erhalten, die jetzt auf einen aktualisierten Link verweist: Eine groß angelegte Studie über Programmiersprachen und

— Codequalität

5

Je weniger mächtig eine Sprache ist, desto weniger Möglichkeiten bietet sie Ihnen, Ihren eigenen Fuß zu schießen.

Hochsprachen wie Java und C # verursachen weniger Fehler als Niedrigsprachen wie C ++.

Allerdings glaube ich, dass Java sicherer ist als C #. Java ist künstlich begrenzt, so dass ein durchschnittlicher Programmierer ohne fortgeschrittene Kenntnisse es beherrschen und stabile Programme erstellen kann.

— user8685
quelle

4

+1 für "Je weniger mächtig eine Sprache ist, desto weniger Möglichkeiten gibt sie dir, deinen eigenen Fuß zu schießen."

— Michael K

Das Diagramm von missingfaktor scheint zu sagen, dass C # und C ++ "gleichberechtigt" sind, soweit es darum geht, sich selbst zu erschießen, und Java darüber erhebt. Nicht, dass ich dem Teil der Tabelle zustimme. Sie sind gezwungen, durch die Reifen zu gehen, um einige C # -Schüsse zu machen.

— Jesse C. Slicer

6

Sicherheit und Kraft sind nicht umgekehrt proportional (was Sie zu denken scheinen ;-) Haskell zum Beispiel ist EXTREM kraftvoll und hat doch nur sehr wenige Möglichkeiten, sich selbst in den Fuß zu schießen.

— Fehlender Faktor

3

Wenn die Sprache schwach ist, brauchen Sie nur einen größeren Fuß.

7

@missingfaktor, das liegt daran, dass es ein Nebeneffekt ist, sich in den Fuß zu schießen.

3

Mit welcher Sprache kann der durchschnittliche Programmierer Ihrer Meinung nach Funktionen mit der geringsten Anzahl schwer zu findender Fehler ausgeben?

Meiner Meinung nach Delphi. Da die Sprache auf Pascal basiert, ist sie für den durchschnittlichen Programmierer (oder auch für unerfahrene Programmierer) einfach und intuitiv genug , um leicht gefunden zu werden, und dank ihrer umfangreichen Tool- und Bibliotheksunterstützung sind die meisten Fehler leicht zu finden.

Starke Typisierung und ein strenger Compiler, der viele häufige Fehler abfängt.
Intuitive Syntax, die keine häufigen Fehler hervorruft. ("The World's Last Bug" if (alert = RED) {LaunchNukes;}wird beispielsweise nicht kompiliert.)
Ein gut entworfenes Objektmodell, das viele der gängigen C ++ - OOP-Fehler beseitigt.
In die Sprache integrierte Bounds-Checks und Range-Checks reduzieren das Risiko von Sicherheitsproblemen drastisch.
Wahrscheinlich der schnellste Compiler, der dem Menschen bekannt ist, was Ihre Produktivität steigert und es schwieriger macht, Ihren Gedankengang zu verlieren, während Sie auf einen Build warten.
Der Debugger von Visual Studio soll so aussehen, wie er aufwächst.
Die Leckverfolgung ist direkt in den Speichermanager integriert, wodurch das Auffinden und Beheben von Speicherlecks trivial wird.
Eine große, ausgereifte Standardbibliothek, die vorgefertigte und vorab getestete Möglichkeiten bietet, um allgemeine Aufgaben zu erledigen, ohne eigene, möglicherweise fehlerhafte Implementierungen erstellen zu müssen.
Wird mit nützlichen Tools wie einem leistungsstarken Protokollierungssystem und einem Profiler geliefert, um das Auffinden von Problemen zu vereinfachen.
Starke Community-Unterstützung für häufig auftretende Probleme, die nicht in der Standardbibliothek enthalten sind, einschließlich einer leistungsstarken Fremdanbieter-Parallelbibliothek .

— Mason Wheeler
quelle

Ich bin von jeher ein Delphi-Jockey, aber es hat sich von den Pascal-Wurzeln gelöst, als es mir erlaubte, irgendetwas in irgendetwas anderes zu tippen, a la C / C ++:var I: Integer; Pointer(I)^ := $00;

— Jesse C. Slicer

1

@Jesse: Vielleicht, aber ich sehe das als notwendiges Zugeständnis an den Pragmatismus. Kernighan machte viele gute Punkte, als er schrieb, warum Pascal nicht meine Lieblingsprogrammiersprache ist. Typecasts sind notwendig, um viele wichtige Dinge auf niedriger Ebene zu erledigen. Eine der Stärken von Delphi ist jedoch die Art und Weise, wie die Bibliotheken Low-Level-Details kapseln und die meisten unsicheren Zeiger- und typografischen Elemente überflüssig machen.

— Mason Wheeler

Ich bin nicht anderer Meinung, dass es notwendig sein könnte - aber das Behaupten von Strong Typing wird dadurch etwas negiert. Original Pascal erlaubte solche Spielereien nicht und war deshalb stark getippt. Aber ich würde nicht so weit gehen, Delphi mit schwacher Typisierung zu bezeichnen - es ist eine Art "mittelgroße Typisierung".

— Jesse C. Slicer

1

@Jesse: Hat die ursprüngliche Wirth-Version von Pascal keine Variantendatensätze zugelassen? Im IIRC wurden sie schließlich so häufig verwendet, um starkes Tippen zu untergraben, dass Borland und andere beschlossen, nur Typografien einzufügen, um es einfacher zu machen, weil es sowieso jeder tat.

— Mason Wheeler

en.wikipedia.org/wiki/Pascal_(programming_language)#Divisions und en.wikipedia.org/wiki/Pascal_(programming_language)#Criticism sowie pascal-central.com/ppl/chapter3.html scheinen darauf hinzudeuten, dass es Teil von war Ich sehe einige Referenzen von Wirth, die auf 1974 zu datieren scheinen, also würde ich sagen, dass dies der Fall ist. Ich denke, der problematische Teil bestand darin, dass man es als solches untergraben konnte (dh dass die varianten Felder denselben Speicher beanspruchten, wie die Gewerkschaften in C). Wenn sie einfach als Suchmechanismus verwendet würden und das Speicherlayout für die Obermenge wäre, wäre sie stärker typisiert.

— Jesse C. Slicer

2

Eine Sache, die berücksichtigt werden muss, ist die Bearbeitungszeit.

In den letzten fünf Jahren habe ich hauptsächlich Webanwendungen in Java (JSF, Seam usw.) entwickelt. Vor kurzem habe ich einen neuen Job bekommen und wir verwenden Perl (mit Catalyst und Moose).

In Perl bin ich viel produktiver als in Java.

Nicht kompilieren und (Hot-) Deployen zu müssen, ist ein Grund. Ich finde auch, dass das Schreiben von Use Cases einfacher ist, da es iterativer durchgeführt werden kann. Und die Frameworks in Java scheinen unnötig komplex zu sein, zumindest für die Projekte, an denen ich beteiligt war.

Ich denke, die Anzahl der Fehler in meinem Perl-Code ist mehr oder weniger die gleiche wie die Anzahl der Fehler in meinem Java-Code, sie könnte sogar höher sein. Aber ich finde es einfacher und schneller, diese Fehler zu finden und zu beheben.

— slu
quelle

1

Ein Überblick über die Anzahl der Tools, die für die statische und dynamische Code-Analyse für jede Programmiersprache verfügbar sind, könnte eine Idee liefern. Je mehr Tools für eine Sprache verfügbar sind, desto wahrscheinlicher ist es, dass die Sprache entweder bei Benutzern sehr beliebt ist oder bei der Erzeugung schwer zu findender Fehler sehr beliebt ist. Es ist mir jedoch nicht möglich, Google auf eine Studie zu diesem Thema aufmerksam zu machen. Es sollte auch beachtet werden, dass einige Sprachen wie C verwendet werden können, um die zugrunde liegenden Hardwarefehler zu umgehen, sowie um den Verschleiß der Hardware mit zunehmendem Alter zu umgehen.

— vpit3833
quelle

1

"Die Abnutzung der Hardware mit zunehmendem Alter umgehen" ...?

— j_random_hacker

Ich habe gelesen, dass einige Unix-Betriebssysteme, die auf unternehmenskritischen Computern ausgeführt werden, den Zustand von CPU, RAM und anderer Hardware überprüfen. serverfault.com/questions/56192/… erörtert dies bis zu einem gewissen Grad . Wenn einige Zeilen in einem RAM-Modul mit der Zeit fehlerhaft werden, werden diese fehlerhaften Module vom Betriebssystem nicht verwendet und im gesamten verfügbaren physischen Speicher nicht gemeldet. Solche Dinge könnten auch auf anderer Hardware ausgeführt werden.

— vpit3833

Das ist ein interessanter Leckerbissen, aber ich verstehe nicht, wie wichtig er hier ist. In Ihrem Link steht auch nichts über diese selbstreparierenden Unix-Betriebssysteme - es geht nur um Möglichkeiten, die Hardware eines PCs einem Stresstest zu unterziehen.

— j_random_hacker

1

Ich erwähnte es, um zu bedeuten, dass Programme allein möglicherweise nicht die Fehlerquellen sind, sondern auch die Hardware oder andere externe Faktoren.

— vpit3833

1

Anstatt über Sprachen zu sprechen, sollten Sie über Sprachmerkmale sprechen

Java zwingt Sie zum Nachdenken über Ausnahmen (Throws ...) und Sie müssen diese entweder veröffentlichen oder behandeln. Verhindert das wirklich, dass ich Fehlersituationen vergesse, oder verwende ich mehr Ausnahmen, die von SystemException abgeleitet sind und diese Behandlung nicht benötigen?
Was ist mit "Design by Contract" (http://en.wikipedia.org/wiki/Design_by_contract), das mich zwingt, über Vor- und Nachbedingungen nachzudenken? Ich habe gelesen, dass das jetzt mit c # -4.0 möglich ist.

— k3b
quelle