Heiko L. schrieb:> Du kennst den Unterschied zwischen Einheit und Betrag doch.> Wenn man statt 5m 5ft schreibt, ist es falsch. Das geht auch mit> Length<feet>(5) oder ähnlichem.
Selbstverständlich kann ich eine Entfernung falsch abgeben.
Ich kann auch einfach die falsche Formel für den schiefen Wurf ansetzen.
Ich kann N Fehler machen. Aber wenn ich durch ganz einfache Maßnahmen
schon einige dieser Fehler ausschließen kann, bin ich schon ein Stück
weiter.
Hinzu kommt noch, das
1
Meterd=1_m;
selbsterklärend ist, was
1
doubled=0.001;
nicht ist.
Der Leitsatz ist: eine Schnittstelle sollte leicht richtig und schwer
falsch zu benutzen sein!
Wilhelm M. schrieb:> Der Leitsatz ist: eine Schnittstelle sollte leicht richtig und schwer> falsch zu benutzen sein!
Na das wird aber schwierig, wenn alle Typen maximal restringiert sind
und jedes Modul seine eigenen Einheiten definiert.
Da hätte ich dieses passende Beispiel aus dem Bereich 3d-Grafik.
Grundsätzlich hat da echt JEDE lib, die man benutzt seinen eigenen
"Vector" definiert. Da passiert es dann schon mal, dass beim Umformen
etwas falsch läuft... (buffer overflow)
Heiko L. schrieb:> Wilhelm M. schrieb:>> Der Leitsatz ist: eine Schnittstelle sollte leicht richtig und schwer>> falsch zu benutzen sein!>> Na das wird aber schwierig, wenn alle Typen maximal restringiert sind> und jedes Modul seine eigenen Einheiten definiert.> Da hätte ich dieses passende Beispiel aus dem Bereich 3d-Grafik.> Grundsätzlich hat da echt JEDE lib, die man benutzt seinen eigenen> "Vector" definiert. Da passiert es dann schon mal, dass beim Umformen> etwas falsch läuft... (buffer overflow)
Na dann gibt doch mal ein konkretes Beispiel ...
Wilhelm M. schrieb:> Dann bist du wahrscheinlich auch der Meinung, dassdouble distance1 => 42.0; // km?> double distance2 = 1.0; // mm? cm? who knows ...> double l = distance1 + distance2;> einen Wert in l von etwa 43.0 ergeben sollte?
Hier hast du noch selbst double für eine distance verwendet, als
sinnvolles Beispiel im Gegensatz zur "sinnlosen" Addition von
Fehlercodes. :)
Also was stimmt nun, sind nun alle Operationen der double-Arithmetik auf
Distanzen sinnvoll und ist double ein geeigneter Datentyp für Distanzen
(OHNE die Einheit zu berücksichtigen)?
Tja, hinterher ist man immer schlauer und weiß, wie es besser gewesen
worden wäre, nech. ;)
batman schrieb:> Wilhelm M. schrieb:>> Dann bist du wahrscheinlich auch der Meinung, dassdouble distance1 =>> 42.0; // km?>> double distance2 = 1.0; // mm? cm? who knows ...>> double l = distance1 + distance2;>> einen Wert in l von etwa 43.0 ergeben sollte?>> Hier hast du noch selbst double für eine distance verwendet, als> sinnvolles Beispiel im Gegensatz zur "sinnlosen" Addition von> Fehlercodes. :)
Hast Du es auch gelesen, das Beispiel?
Du meinst also auch 42km + 1mm = 43km ?
Und schon ist die Raumsonde wieder vorbei ...
> Also was stimmt nun, sind nun alle Operationen der double-Arithmetik auf> Distanzen sinnvoll und ist double ein geeigneter Datentyp für Distanzen> (OHNE die Einheit zu berücksichtigen)?
Distanzen sind ohne Einheit gar nicht darstellbar.
batman schrieb:> Wilhelm M. schrieb:>> Dann bist du wahrscheinlich auch der Meinung, dassdouble distance1 =>> 42.0; // km?>> double distance2 = 1.0; // mm? cm? who knows ...>> double l = distance1 + distance2;>> einen Wert in l von etwa 43.0 ergeben sollte?>> Hier hast du noch selbst double für eine distance verwendet, als> sinnvolles Beispiel im Gegensatz zur "sinnlosen" Addition von> Fehlercodes. :)>> Also was stimmt nun, sind nun alle Operationen der double-Arithmetik auf> Distanzen sinnvoll und ist double ein geeigneter Datentyp für Distanzen> (OHNE die Einheit zu berücksichtigen)?>> Tja, hinterher ist man immer schlauer und weiß, wie es besser gewesen> worden wäre, nech. ;)
Du hast weder kapiert dass das Distanz Beispiel ein DONT und kein DO
war, noch siehst du die Vorteile starker Typisierung bei der Arithmetik.
Also... nein, du bist hinterher nicht schlaucher, "nech". ;)
Wilhelm M. schrieb:> Na dann gibt doch mal ein konkretes Beispiel ...
Warum es problematisch ist, verschiedene Vector-Klassen mit OpenGL zu
verwenden? Weil man immer an den Punkt kommt, wo man die Werte verwenden
muss.
Da passiert es dann u.U. dass man glColor4fv schreibt, wo glColor3fv
stehen müsste, wenn da zu viele Sachen durcheinander fliegen. C++ macht
die Sache da potentiell noch unübersichtlicher, weil man dort ggf.
implizite Conversions über primitive Typen triggern kann, die man aber
leider braucht, weil der Source-Code sonst so clumsy wird.
Und das ist bei Sensoren nicht anders: in welcher Einheit arbeit das
Ding?
Genauso wenig wie beim Datenaustausch im Netzwerk: Kommen die Werte in
Big oder Little Endian?
Ich würde wetten, dass das ganze NASA Zeugs in ADA geschrieben war und
es trotzdem nichts genützt hat...
Heiko L. schrieb:> Ich würde wetten, dass das ganze NASA Zeugs in ADA geschrieben war und> es trotzdem nichts genützt hat...
Die Sache war etwas komplexer, und natürlich hätte C++ hier nichts
genutzt.
"The problem involved reading data from a file and a miscommunication
about what the numbers in the file were. I don't know of any language,
no matter how type-strict, that forces you to tag the string "123.45" in
a file with the units of force (newtons vs foot-pounds), nor do I know
of any language, no matter how type-loose, in which you could not impose
such a convention if you wanted to."
Dazu kam dann noch, daß der Code ohne ausreichendes Review
wiederverwendet wurde, obwohl seine Wichtigkeit von "reines Logfile" zu
"missionsentscheidend" angestiegen war. Außerdem waren die Teams strikt
getrennt. Die Bodenmannschaften am Ende waren auch noch unerfahren,
sonst hätten sie das rechtzeitig bemerken können.
Übrigens wurde die Anomalie frühzeitig durchaus entdeckt, aber die
Reports dazu wurden ignoriert.
https://skeptics.stackexchange.com/questions/7276/was-nasa-s-mars-climate-orbiter-lost-because-engineering-teams-used-different-me
Nop schrieb:> Richtig macht man das so, daß man in einem einzigen Datenformat und> einer einzigen Einheit rechnet, und zwar konsistent und überall. Bei> Bedarf kann bei der Ausgabe in andere Datentypen oder Einheiten> konvertiert werden.
Ein Großteil der Diskussion um Einheiten hier resultiert wohl daher,
dass einige den Sinn der Sätze nicht erfasst haben, weil sie selber noch
nicht an dem Punkt waren.
Ein auch im metrischen häufiges Beispiel wären Winkel, wo man Rad (für
Mathe) und Grad (für Nutzer) braucht.
Nop schrieb:> Heiko L. schrieb:>>> Ich würde wetten, dass das ganze NASA Zeugs in ADA geschrieben war und>> es trotzdem nichts genützt hat...>> Die Sache war etwas komplexer, und natürlich hätte C++ hier nichts> genutzt.>> "The problem involved reading data from a file and a miscommunication> about what the numbers in the file were. I don't know of any language,> no matter how type-strict, that forces you to tag the string "123.45" in> a file with the units of force (newtons vs foot-pounds), nor do I know> of any language, no matter how type-loose, in which you could not impose> such a convention if you wanted to."
Natürlich hätte C++ da nichts genützt. Aber das Prinzip der strong types
lässt sich doch 1:1 Übertragen. In die Datei gehört neben dem Betrag der
Kraft auch die Einheit. Natürlich kann man dann immer noch Fehler machen
und man kann die Einheit einfach ignorieren. Aber es gibt keine
Unklarheit über die Einheit dieses Werts.
> Dazu kam dann noch, daß der Code ohne ausreichendes Review> wiederverwendet wurde, obwohl seine Wichtigkeit von "reines Logfile" zu> "missionsentscheidend" angestiegen war. Außerdem waren die Teams strikt> getrennt. Die Bodenmannschaften am Ende waren auch noch unerfahren,> sonst hätten sie das rechtzeitig bemerken können.>> Übrigens wurde die Anomalie frühzeitig durchaus entdeckt, aber die> Reports dazu wurden ignoriert.>> https://skeptics.stackexchange.com/questions/7276/was-nasa-s-mars-climate-orbiter-lost-because-engineering-teams-used-different-me
Das zeigt doch noch um so deutlicher, wie wichtig es ist Fehler so früh
wie möglich zu verhindern, in diesem Fall indem man den Wert mit einer
Einheit ausstattet.
mh schrieb:> In die Datei gehört neben dem Betrag der Kraft auch die Einheit.
Genau das steht doch in dem Zitat - und das hätte man auch in einer
Sprache mit schwacher bis fehlender Typisierung machen können. Man hätte
es auch in C machen können. Hat man aber nicht, und DAS war das Problem.
Auch C++ hätte einen nicht gezwungen, Einheiten in die Datei zu
schreiben - und man hätte es daher auch in C++ nicht gemacht. Und zwar
aus denselben Gründen, wieso man es in der Realität nicht gemacht hat.
Nop schrieb:> mh schrieb:>>> In die Datei gehört neben dem Betrag der Kraft auch die Einheit.>> Genau das steht doch in dem Zitat - und das hätte man auch in einer> Sprache mit schwacher bis fehlender Typisierung machen können. Man hätte> es auch in C machen können. Hat man aber nicht, und DAS war das Problem.>> Auch C++ hätte einen nicht gezwungen, Einheiten in die Datei zu> schreiben - und man hätte es daher auch in C++ nicht gemacht. Und zwar> aus denselben Gründen, wieso man es in der Realität nicht gemacht hat.
Ok ... möchtest du vllt noch ein paar Wörter in dem Zitat weglassen,
wenn du die anderen Sätze schon weglässt?
mh schrieb:> Ok ... möchtest du vllt noch ein paar Wörter in dem Zitat weglassen,> wenn du die anderen Sätze schon weglässt?
Ich bin auf das Wesentliche eingegangen. Das Zitat von Norvig hat Deinen
Punkt schließlich schon vorweggenommen.
Die Problematik beim Mars Orbiter ist dieselbe wie in diesem Thread
generell:
Hier gibt es Leute, die sagen:
A) Es ist doch alles dokumentiert, es kann deswegen nichts schief gehen.
oder
B) Wir wissen, dass es nicht gut / falsch ist. Deswegen ändern wir es
nicht.
Genauso wurde damals gehandelt.
Es ist schon erschütternd, das manche nicht einmal die Chance ergreifen,
Dinge zu verbessern.
Aus der Rezension zu "Elements of Programming":
Ask a mechanical, structural, or electrical engineer how far they would
get without a heavy reliance on a firm mathematical foundation, and they
will tell you, not far. Yet so-called software engineers often
practice their art with little or no idea of the mathematical
underpinnings of what they are doing. And then we wonder why software is
notorious for being delivered late and full of bugs, while other
engineers routinely deliver finished bridges, automobiles, electrical
appliances, etc., on time and with only minor defects.
Wilhelm M. schrieb:> Yet so-called software engineers often> practice their art with little or no idea of the mathematical> underpinnings of what they are doing.
Sowas wie z.B. OOP hat auch keine mathematische Grundlage. Und im
Übrigen braucht man sich nur mal Code von Mathematikern und
Wissenschaftlern anzuschauen, diese Fortranwüsten (auch dann, wenn sie
nicht in Fortran geschrieben sind).
Konkret zum Mars-Orbiter hätte mein Vorschlag von 1500 Postings weiter
oben geholfen: man rechnet projektübergreifend immer im selben System.
Das schafft Konsistenz. Dazu hätte man keine abgefahrene Arithmetik
gebraucht, die hier im Übrigen wegen der Schnittstelle der Datei sowieso
nicht geholfen hätte.
Nop schrieb:> Wilhelm M. schrieb:>> Yet so-called software engineers often>> practice their art with little or no idea of the mathematical>> underpinnings of what they are doing.>> Sowas wie z.B. OOP hat auch keine mathematische Grundlage. Und im> Übrigen braucht man sich nur mal Code von Mathematikern und> Wissenschaftlern anzuschauen, diese Fortranwüsten (auch dann, wenn sie> nicht in Fortran geschrieben sind).
Du hast offensichtlich sowas von keine Ahnung, was Mathematiker und
Wissenschafler für Software schreiben.
mh schrieb:> Du hast offensichtlich sowas von keine Ahnung, was Mathematiker und> Wissenschafler für Software schreiben.
Ich hab davon so einiges gesehen, danke der Nachfrage.
Nop schrieb:> Wilhelm M. schrieb:>> Yet so-called software engineers often>> practice their art with little or no idea of the mathematical>> underpinnings of what they are doing.>> Sowas wie z.B. OOP hat auch keine mathematische Grundlage.
Ja, wissen wir mittlerweile: nur 2'er-Komplimentarithmetik des Datentyps
int ist wahre Mathematik ;-)
Kennst Du das Buch überhaupt, auf das sich die Rezension bezieht?
> Und im> Übrigen braucht man sich nur mal Code von Mathematikern und> Wissenschaftlern anzuschauen,
Genau: Ritchie war Mathematiker, Keringhan war Physiker, Thompson war
E-Techniker. LOL!
> Konkret zum Mars-Orbiter hätte mein Vorschlag von 1500 Postings weiter> oben geholfen: man rechnet projektübergreifend immer im selben System.
Ja genau: hat ja wahnsinnig geholfen.
> Das schafft Konsistenz. Dazu hätte man keine abgefahrene Arithmetik> gebraucht,
Von den Grundrechenarten einige weg zu lassen ist für die schon
abgefahrene Arithmetik. WoW! Kein Wunder, dass Du mit anderen Dingen
schnell überfordert bist.
Wilhelm M. schrieb:> Ja genau: hat ja wahnsinnig geholfen.
Hätte geholfen - wenn man ihn denn gemacht hätte. Vorschläge, die man
nicht macht bzw. verwirft, helfen nicht soviel. D'oh!
> Von den Grundrechenarten einige weg zu lassen ist für die schon> abgefahrene Arithmetik.
Es geht nicht um "weglassen". Worum es geht, habe ich mehrfach erklärt.
Wenn Du es nicht verstehst, lies es nochmal nach - diesmal möglichst
sinnerfassend.
Blöd ist, überhaupt erst auf die Idee zu kommen, man könne Flugbahnen
(oder in diesem Fall - Drehmomente) mit irgendwas anderem als mit
SI-Einheiten berechnen (so was kann nur einem Ami einfallen, ich rechne
ja auch nicht mit kp/Elle, was wertmässig etwa auf dasselbe rauskäme).
Noch blöder ist, wenn die verwendete Einheit (foot-pound) nur um den
Faktor 1,35 "daneben" liegt, da helfen auch "ingenieurmässige
Überschlagsrechnungen" angesichts der sowieso vorhandenen
Ungenauigkeiten wenig.
Aus diesem Kardinalfehler Softwareengineering-Regeln ableiten zu wollen,
erscheint mir persönlich etwas weit hergeholt.
Wilhelm M. schrieb:> Es ist schon erschütternd, das manche nicht einmal die Chance ergreifen,> Dinge zu verbessern.>> Aus der Rezension zu "Elements of Programming":>> Ask a mechanical, structural, or electrical engineer how far they would> get without a heavy reliance on a firm mathematical foundation, and they> will tell you, not far. Yet so-called software engineers often> practice their art with little or no idea of the mathematical> underpinnings of what they are doing. And then we wonder why software is> notorious for being delivered late and full of bugs, while other> engineers routinely deliver finished bridges, automobiles, electrical> appliances, etc., on time and with only minor defects.
Statt ein Buch zu lesen, das erklärt, wie man seine Programme mit viel
Mühe mathematisch untermauert, könnte man auch eine Programmiersprache
lernen, die diese Untermauerung schon von vornherein mitbringt, nämlich
Haskell.
Das Sprachkonzept, das Typsystem, die in der Standardbibliothek
vordefinierten Typen und Typklassen und nicht zuletzt die Syntax sind
stärker als bei allen anderen mir bekannten Programmiersprachen
mathematisch beeinflusst. Zudem erzwingt die Sprache eine mathematische
Denkweise des Programmierers, weswegen schlampige Programmierung in
Haskell sehr schwer ist.
Der Softwarebug des Mars-Orbiters hat seine Ursache aber nicht in der
fehlenden mathematischen Untermauerung der Software, sondern ganz
einfach in der fehlenden Kommunikation zwischen den Entwicklern. Reden
diese nicht miteinander, hilft auch noch so viel Mathematik nicht,
Fehler zu vermeiden.
Niemand wird daran gehindert, die "distance" Klasse inklusive
Stream-Io-Operatoren zu implementieren. Dann MUSS eben in der Datei eine
Einheit dabei stehen. Und dann ist es egal, ob man Unterarme, Daumen
oder Füße als Referenz benutzt oder ob man auf klimatisierte
Edelmetallzylinder schwört, das Ergebnis in der eingelesenen Variable
ist eine Distanz.
Carl D. schrieb:> Dann MUSS eben in der Datei eine Einheit dabei stehen.
Die hätte man aber selbst dann haben können, wenn die schreibende Seite
in DOS-Basic gewesen wäre. Dann wäre übrigens der anderen Projektseite
auch klar gewesen, was da eigentlich steht, selbst wenn die in
Excelmacros gearbeitet hätte.
Der Punkt ist, daß das eben nicht gemacht wurde. Der Einheitenfehler kam
eben nicht so zustande, wie hier im Thread zunächst suggeriert wurde.
Nop schrieb:> Carl D. schrieb:>> Dann MUSS eben in der Datei eine Einheit dabei stehen.>> Die hätte man aber selbst dann haben können, wenn die schreibende Seite> in DOS-Basic gewesen wäre. Dann wäre übrigens der anderen Projektseite> auch klar gewesen, was da eigentlich steht, selbst wenn die in> Excelmacros gearbeitet hätte.>> Der Punkt ist, daß das eben nicht gemacht wurde. Der Einheitenfehler kam> eben nicht so zustande, wie hier im Thread zunächst suggeriert wurde.
Man kann das sogar in Assembler manchen, aber es sollte eben
"Easy TO use correct"
und
"Difficult TO use incorrect"
Denn codierende Dumpfbacken findet man überall und muß man halt
irgendwie unter Kontrolle bringen. Alternativ abschrecken und damit los
werden. Klappt!
Carl D. schrieb:> Man kann das sogar in Assembler manchen, aber es sollte eben> "Easy TO use correct"> und> "Difficult TO use incorrect"
Das wäre durch Einheiten in der Datei bereits erfüllt worden, ebenso wie
durch konsistente Benutzung ein- und desselben Einheitensystems im
ganzen Projekt. Das ganze Beispiel taugt somit eben nicht zur
Untermauerung von Spezialarithmetik, die in diesem Fall den Fail auch
nicht verhindert hätte - denn an dem Punkt, wo die zum Zug gekommen
wäre, wäre der Fehler bereits passiert gewesen.
Einfach mal hören "Mars-Sonde, Einheitenfehler" und dann drauflos
argumentieren funktioniert so nicht.
Nop schrieb:> Carl D. schrieb:>>> Man kann das sogar in Assembler manchen, aber es sollte eben>> "Easy TO use correct">> und>> "Difficult TO use incorrect">> Das wäre durch Einheiten in der Datei bereits erfüllt worden, ebenso wie> durch konsistente Benutzung ein- und desselben Einheitensystems im> ganzen Projekt. Das ganze Beispiel taugt somit eben nicht zur> Untermauerung von Spezialarithmetik, die in diesem Fall den Fail auch> nicht verhindert hätte - denn an dem Punkt, wo die zum Zug gekommen> wäre, wäre der Fehler bereits passiert gewesen.>> Einfach mal hören "Mars-Sonde, Einheitenfehler" und dann drauflos> argumentieren funktioniert so nicht.
Die "Spezialarithmetk" wäre schon durch den ersten Test gefallen, hätte
sie Zahlensalat ohne Einheiten vorgefunden.
Ich z.B. bin froh, daß mein Gehalt mit Wert und Einheit überwiesen wird
und keiner unterwegs Rätseln muß ob das Euro oder Rupien sein sollen.
Das Mars-Problem war nicht, daß die Teams nicht vereinbart hatten, was
in der Datei stehen soll, sondern daß sie es nicht reingeschrieben
haben. Dazu brauch ich keinen Bericht lesen, das kann mein Hirn
selbstständig ableiten.
Carl D. schrieb:> Das Mars-Problem war nicht, daß die Teams nicht vereinbart hatten, was> in der Datei stehen soll, sondern daß sie es nicht reingeschrieben> haben.
Eben. Hätten sie es aber getan, dann wäre auf der Empfängerseite mit
ganz banaler double-Arithmetik alles paletti gewesen.
Sie haben es übrigens deswegen nicht reingeschrieben, weil der Code
ursprünglich bloß für eine unwesentliche Log-Funktion war - und dank
Wiederverwendung dann auf einmal missionsentscheidend wurde.
Direkte Wiederverwendung von Code ist keine so gute Idee, wenn dabei
dessen Wichtigkeitsstufe massiv ansteigt. Wie man schon aus menschlicher
Textanalyse weiß, ist Text eben nicht nur ein Dokument, hier der Code,
sondern eben auch das, was nicht im Dokument selber steht, also der
Kontext.
Das ist eine Erkenntnis, die ausgerechnet für Geisteswissenschaftler
absolut trivial gewesen wäre, die aber in "hard sciences" oftmals
untergeht.
“Numbers as invented by mathematicians are abstract and beautiful. This
should not be spoiled by engineers”
(Die Reaktion vor 50 Jahren, mit der Einheitenrechnungen der Ingenieure
abgewiegelt wurden)
Warum glauben so viele, man könne dem Einheitenchaos begegnen, indem man
die Einheiten mit Magie irgendwie konvertiert?
Das Gegenteil ist der Fall.
Wenn man 1 au + 1 mm rechnet, dann kann man das in C++ sicher machen mit
Operatorüberladung und Typen.
Sinnvoll ist es trotzdem nicht, denn das Programm ist trotzdem falsch.
Z.B. Rundungsfehler werden so nur noch besser vor dem Programmierer
versteckt. (vgl. https://en.wikipedia.org/wiki/Loss_of_significance )
Besser einigt man sich global im Projekt auf sinnvolle Einheiten und
verwendet diese dann konsistent.
Dabei hilft einem die Programmiersprache kaum.
Interfaces definieren ist ein soziales und kein technisches Problem.
MaWin schrieb:> Interfaces definieren ist ein soziales und kein technisches Problem.
Wobei diese Architektur mit zwei Systemen und verschiedenen
Einheitensystemen dafür ja ein Beispiel ist - Stichwort "Conways's Law".
Und ja, soziale Probleme mit technischen Mitteln lösen zu wollen
funktioniert meistens nicht - was Geeks nicht daran hindert, es immer
wieder zu versuchen. Liegt auch daran, daß sie die Problemklasse oftmals
nur mangelhaft verstehen.
Nop schrieb:> Carl D. schrieb:>>> Das Mars-Problem war nicht, daß die Teams nicht vereinbart hatten, was>> in der Datei stehen soll, sondern daß sie es nicht reingeschrieben>> haben.>> Eben. Hätten sie es aber getan, dann wäre auf der Empfängerseite mit> ganz banaler double-Arithmetik alles paletti gewesen.>> Sie haben es übrigens deswegen nicht reingeschrieben, weil der Code> ursprünglich bloß für eine unwesentliche Log-Funktion war - und dank> Wiederverwendung dann auf einmal missionsentscheidend wurde.
Ok, in Summe: weil man sich keine Mühe gemacht hat, es von Anfang an
richtig zu machen, ist richtig machen blöd.
Typische Ausrede für Frickel-Code, "reicht doch so", die ich in 30Jahren
Softwareentwicklung oft genug gehört hab.
> Direkte Wiederverwendung von Code ist keine so gute Idee, wenn dabei> dessen Wichtigkeitsstufe massiv ansteigt.
Wenn er eben nach der Methode "reicht schon" hingeschmiert wurde. Wenn
es dabei um Aufwand gehen sollte, dann könnte man auch nach dem Risiko
fragen. 5Tage gespart + x% Risiko einen 9-Stelligen Betrag zu verlieren.
Eigentlich eine simple Rechnung. Zumal "richtig" oft nicht länger
dauert, nur eben halt bei manchen länger als ihre Laufzeit.
> Wie man schon aus menschlicher> Textanalyse weiß, ist Text eben nicht nur ein Dokument, hier der Code,> sondern eben auch das, was nicht im Dokument selber steht, also der> Kontext.>> Das ist eine Erkenntnis, die ausgerechnet für Geisteswissenschaftler> absolut trivial gewesen wäre, die aber in "hard sciences" oftmals> untergeht.
Geisteswissenschaftler mögen über den Inhalt einer Datei diskutieren und
ihn interpretieren, wie sie wollen. Bei dem Projekt waren Ingenieure
gefragt, die legen fest.
Carl D. schrieb:> Wenn er eben nach der Methode "reicht schon" hingeschmiert wurde.
Nein.
Jedes Programm, jeder Programmabschnitt, hat eine Anforderung.
Die Anforderungen an Code der printf befüttert sind ganz andere, als die
Anforderungen an Code, der Steuerdüsen befeuert.
Wenn jetzt ein Entwickler hingeht und eine printf-Funktion einfach so
zur Ansteuerung von Steuerdüsen wiederverwendet, dann ist das
Anforderungsmanagement sehr sehr sehr sehr kaputt. Oder hat der
Entwickler einfach ignoriert, dass die Anforderungen der Funktion gar
nicht zu seinen Anforderungen passen? Das ist ein massiver Fehler in
der Softwareentwicklung. Und zwar lange bevor auch nur eine Zeile des
fehlerhaften Codes geschrieben wurde.
Der kleinste Teil der Softwareentwicklung ist die Programmierung.
Carl D. schrieb:> Ok, in Summe: weil man sich keine Mühe gemacht hat, es von Anfang an> richtig zu machen, ist richtig machen blöd.
Hat zwar nichts mit dem zu tun, was ich geschrieben habe, aber wird
schon passen.
> Wenn er eben nach der Methode "reicht schon" hingeschmiert wurde.
Man hat für den unwichtigen Code, ALS er unwichtig war, einen
Junior-Entwickler drangesetzt. In der realen Welt hat man nicht die
Ressourcen, auch die unwichtigen Sachen von den Obercracks machen zu
lassen, weil es für die Menge an Code, die weltweit gebraucht wird,
nicht genug Obercracks gibt.
Das ist auch völlig in Ordnung so - nur die Hochstufung war eben nicht
OK. In normaler Luftfahrt wäre es ja auch nicht möglich, daß man Code
aus einem unwichtigen System wie Inflight-Entertainment hernimmt, den
mal eben in den Turbinencontroller setzt und mit "paßt schon" abnickt.
> Geisteswissenschaftler mögen über den Inhalt einer Datei diskutieren und> ihn interpretieren, wie sie wollen. Bei dem Projekt waren Ingenieure> gefragt, die legen fest.
Oder auch nicht. Schlimmer noch, ihnen war weder beim Code noch bei der
Datei die Bedeutung von "Kontext" bewußt, weswegen sie auch nicht drauf
gekommen sind, daß sie da etwas festlegen hätten sollen. Eben um
relevante Information aus dem Kontext in den Text zu ziehen.
Ändert alles nichts daran, daß die Spezial-Arithmetik zum Vermeiden von
Einheitenfehlern hier weder notwendig noch hinreichend gewesen wäre.
MaWin schrieb:> Warum glauben so viele, man könne dem Einheitenchaos begegnen, indem man> die Einheiten mit Magie irgendwie konvertiert?
Zumal auch nicht alle Einheiten verlustfrei ineinander umgerechnet
werden können. Loss of Significance ist da nur ein Faktor.
Carl D. schrieb:> Ok, in Summe: weil man sich keine Mühe gemacht hat, es von Anfang an> richtig zu machen, ist richtig machen blöd.
Was soll "richtig" denn hier bedeuten? Vermutlich hat der Code genau
seine ursprüngliche Spec erfüllt. Das war einfach Zweckentfremdung nach
dem Motto "Wir brauchen etwas hartes, um den Nagel in die Wand zu
kriegen."
Ein Logfile ist dazu bestimmt, menschenlesbar zu sein und schon deswegen
zur Kommunikation zwischen Systemen völlig ungeeignet.
Heiko L. schrieb:> Carl D. schrieb:>> Ok, in Summe: weil man sich keine Mühe gemacht hat, es von Anfang an>> richtig zu machen, ist richtig machen blöd.>> Was soll "richtig" denn hier bedeuten? Vermutlich hat der Code genau> seine ursprüngliche Spec erfüllt. Das war einfach Zweckentfremdung nach> dem Motto "Wir brauchen etwas hartes, um den Nagel in die Wand zu> kriegen."> Ein Logfile ist dazu bestimmt, menschenlesbar zu sein und schon deswegen> zur Kommunikation zwischen Systemen völlig ungeeignet.
Worin besteht das Problem in einem Logfile 42km von 42inch unterscheiden
zu können? Weil man dann weniger raten kann.
Wenn man Längen protokolliert, dann bestehen die eben aus mehr als einer
Zahl, dannist es menschen- und maschinenlesbar.
Alles andere ist Pfusch, besonders im hunderte-Mega-$/€-Bereich.
Carl D. schrieb:> Worin besteht das Problem in einem Logfile 42km von 42inch unterscheiden> zu können? Weil man dann weniger raten kann.
Es gibt halt unterschiedliche Konventionen in unterschiedlichen
Bereichen. Geschwindigkeiten werden oft nicht in m/s angegeben. Das wird
schon so gewesen sein, wie einstmals gedacht war. In ein Logfile eine
Flughöhe in Inches einzutragen ist absurd, auch wenn es korrekt ist.
S. R. schrieb:> Auch mm oder yards wären korrekt...
Mit Meilen wäre man aber viel flexibler. Die gibt es in Einheiten von
500..11299 SI-Meter. Aber immer wichtig: keine Einheiten reinschreiben!
</ironie>
Wenn ich hier so manches lese, bin ich froh die Schreiber nie persönlich
zu treffen.
Ich sprach nicht von "gut", ich sprach von "korrekt".
Und nein, zwingend Meter oder andere SI-Einheiten in Logfiles schreiben
ist nicht überall die beste Idee. Wenn das intern verwendete
Einheitensystem aus Timer-Ticks und Fixpoint-Arithmetik besteht, ist
eine Float-Umrechnung fürs Log vermutlich sogar ziemlich doof.
Aber was schreibe ich hier, ihr habt die Weisheit natürlich auch alle
mit Löffeln gefressen.
Es ist übrigens völlig normal, daß die Einheit nicht mitgesendet wird.
Das wird es in Autos und Flugzeugen auch nicht. Was es da aber gibt,
sind klare Dokumente, die das Nachrichtenformat im Detail beschreiben,
und da steht die Einheit dann drin.
Thread beobachten
Seitenaufteilung abschalten