Suche "Programmier-Sprachen-Theoretiker"

[gorgoyle]

rapso schrieb:

Was mich beaengstigt ist, dass du damit sogar viele leute ansprechen koenntest.

Das ist keine Kritik sondern eine Wertung.

W0lf schrieb:

Wurden aus diesem Thread einige Posts gelöscht, oder hat rapso tatsächlich nur einen Beitrag dazu geschrieben?

Er hat nur einen Beitrag geschrieben. Wenn ich in den anderen Projekt-Threads suchen sollte nach vergleichbaren Threads kommt entweder heraus dass das ein Einzelfall war oder hier der Normalfall ist.

Aber ich möchte mich hier für die echte Kritik der anderen Poster bedanken. Ich mußte feststellen, daß das Thema Null-Pointer bereits von anderen beackert wurde und dass ich namenhafte Personen finde, wenn ich die QuellenNachweise lese und oft der renomierte Addison-Wesley-Verlag sich der Veröffentlich angenommen hat. Ich stehe also in guter Gesellschaft.

Korbinian schrieb:

Hi,
also ich habe hier noch nichts geloescht. Soll ich?

Subtil wie ein Flammenwerfer in der Nacht. Wurd hier nicht gerade noch meine Kritikfähigkeit in Frage gestellt?

[W0lf]

Korbinian schrieb:

Hi,
also ich habe hier noch nichts geloescht. Soll ich?

volontier

[rapso]

gorgoyle schrieb:

weißt du was das tolle an deiner meinung ist?
das grundgesetz sichert dir das recht zu zu diese zu besitzen und auch noch zu äußern wenn dir danach ist!
ich dagegen verzichte darauf dir meine meinung über dich und deinen post zu äußern außer daß ich eine meinung habe.

nichts zu danken, hab dir gerne gesagt wie du's schon in c++ realisieren kannst ohne das rad neu zu erfinden.

die tatsache dass "fehler" (das sei man so dahin gestellt) nicht mehr mehr zwangsläufig zum Absturz führen als
Nachteil darzustellen, ist eine interessante Position.

Wie du schon sagst, es passieren Fehler und niemand merkt es. Das als vorteil darzustellen ist schon sehr interesant. Sieht man ja gerade am hypothekenmarkt in den USA, jahrelang wurden die kritiker und analysten als miesmacher beschimpft, doch irgendwann bricht das kartenhaus zusammen. Jede lehre kennt die regel, das fehler schlimmere folgen haben je spaeter man sie bemerkt. Das ein Programm nicht abstuerzt ist schoen, aber es ist nicht das ziel vom programmieren, das ziel ist dass es richtig laeuft. Es nuetzt dir garnichts wenn du ein program 24h am stueck ohne absturz laufen lassen kannst und es nur noch ein zombi ist. Es nuetzt dir auch garnichts wenn dir jemand das interface zur datenbank wegzieht und deine wichtige applikation nicht abstuerzt, sondern tagelang ein null-interface benutzt und alle wichtigen daten ins nirvana schickt.
Das ist genau so sinnvoll wie ein GC zu haben mit dem man keine memoryleaks hat und stattdessen programme mit referenzierten speicher vollaufen.
Lies dir vielleicht die aktuellen arbeiten zu programmiersprachen forschung und anayle durch die an vielen instituten gemacht werden. die allermeisten arbeiten darauf hin fehlererkennungen, statisch und zur laufzeit durchzufuehren bzw pattern zu entwickeln die fehlervermeidung mit sich bringen, und das fuer hardware und software.

Frei nach dem Motto: Wer richtig Auto fahren kann, der macht auch keinen Unfall und ist tot! Wozu ein AirBag!

Frei nach dem motto, wozu autofahren, kannst auch ein nullauto..emm.. ich meine simulator benutzen. niemand wird jemals sterben... ist das wirklich ein erstrebenswertes ziel?

Bin zu müd mich mit so einer selbstüberschätzen Meinung auseinanderzusetzen! Behalt deine Meinung für dich dann behalte
ich auch meine für mich!

Du solltest nicht nach leuten Fragen die sich mit sprachen auskennen, wenn du es am ende garnicht vertraegst eine andere meinung zu hoeren (nein, ich selbst bin kein guru, aber ich hab genug wissen um meine meinung zu haben). du scheinst grundlegende dinge wie pattern nicht zu kennen, aber willst eine komplett neue sprache erfinden mit zweifelhaften zielen, die aber auch schon mit bestehenden sprachen leicht zu realisieren waeren.

ich verstehe schon wenn du dich sehr angegriffen fuehlst, aber da sind wir wieder bei der sache mit den fehlern..

da ich aber nicht vor habe mich mit dir zu streiten, werd ich deinen thread nicht weiter belasten auf deinen wunsch hin. Fuer weitere strei..emm.. dialoge red ich gerne mit dir per mail oder chat

[sendro]

gorgoyle schrieb:

Wurd hier nicht gerade noch meine Kritikfähigkeit in Frage gestellt?

Naja, wenn ich Deine Reaktionen hier so lese, dann ja, dann _muss_ man Deine Kritikfähigkeit erheblich in Frage stellen. Du hälst Deine Idee für genial und jeder der das nciht erkennt oder gar in Frage stellt wird sofort von Dir angegriffen und runtergemacht.

gorgoyle schrieb:

die tatsache dass "fehler" (das sei man so dahin gestellt) nicht mehr mehr zwangsläufig zum Absturz führen als Nachteil darzustellen, ist eine interessante Position.

Die Tatsache, das "fehler", nicht mehr zwangsläufig zum Absturz führen _ist_ ein Nachteil, weil es vor allem dem unerfahrenen Programmierer das Gefühl gibt, er würde alles richtig machen. Außerdem bedeutet Exception ja noch lange nciht Programmabsturz. Ein guter Programmierer muß dafür sorgen das im Falle einer Exception sein Programm diese sauber verarbeitet. Das kann durchaus bedeuten das das Programm einfach weiterläuft und den Fehler z.B. nur weglogged.

gorgoyle schrieb:

Frei nach dem Motto: Wer richtig Auto fahren kann, der macht auch keinen Unfall und ist tot! Wozu ein AirBag!

Nein, frei nach dem Motto: Wer einen Fehler macht _muß_ auch die KOnsequenzen zu spüren bekommen, weil er sonst nie aus seinen Fehlern lernen kann. Was Du willst ist eher eine Situation, wo bei jedem Fahrfehler des Autofahreres ein Fußgänger überfahren wird, aber weil die Scheiben alle verdunkelt wurden der Fahrer das nicht mehr mitbekommt und er sich trotzdem weiterhin für einen sicheren und guten Fahrer hält obwohl er es nicht ist. Ohne das Feedback der Fehlermeldung funktioniert auch der Regelkreis des "Try-And-Error" nicht mehr.

gorgoyle schrieb:

So kann leicht an beliebiger Stelle ein Objekt zerstört werden, und in anderen Threads/Code-Stellen, die noch eine Referenz zum zerstörten Objekt haben, können mit ihrer Tätigkeit fortfahren, ohne NullPointerExceptions bzw. SegmentationFaults zu verursachen. Die grundsätzlich notwendigen Konsolidierung der Referenzen kann später stattfinden, um die "Datei-Leichen" herauszufiltern, aber sie lassen den ProgrammAblauf nicht mehr zusammenbrechen bzw. aufwendige Prüfungen bei jedem Zugriff entfallen.

Ok, aber was passiert denn nun in den anderen Threads die auf das bereits zerstörte Objekt zugreifen? Kriegen die einfach "dummy-daten" und arbeiten damit weiter als wären es die echten Daten? Welchen Sinn macht es denn wenn ein Programm mit falschen Daten weiterläuft?

Oder ist es doch so das das Programm dann bemerken muß das es auf ein "totes" Objekt zugreift und entsprechend darauf reagiert? Wenn ja, wie stellst Du Dir das vor? Wieder wie im klassischen Fall wo man vor jedem Zugriff erstmal prüft ob die Daten denn noch gültig sind? Mal abgesehen von potentiellen Race-Conditions sind wir dann wieder in der Zeit von vor ca 20 Jahren...

Was Du vorschlägst, zumindest soweit ich das verstehe, entspricht ungefähr diesem Code: (Nur das Du die Exception ganz verhinderst, was aber im endergebnis auf gleiche hinausläuft)

try
{
   function.doSomething()
}
catch { }

Darin kein Problem zu sehen _ist_ ein Problem...

gorgoyle schrieb:

Es sind zwar noch viele Dinge zu klären, doch verspricht dieser Ansatz einen stabiles System.

Ein stabiles System erhälst Du durch sauberes Design, gute Qualitätssicherung und Programmierer die wissen was sie tuen.

Das von Dir beschriebene System mag ja "stabil" sein im Sinne von "Stürzt nicht ab", jedoch werden seine Zustände unberechenbar und damit auch sein Verhalten. Wenn der Thread im richtigen Moment auf das Objekt zugreift wo es "noch" lebt, kommt das richtige Ergebnis. Greift er einen Cyclus später bekommt er statt dessen das Dummy-Objekt, rechnet damit weiter und erzeugt ein falsches Ergebnis. Die Seiteneffekte eines solchen unpredikteable systems sind imho unberrechenbar. Du hast keinen deterministischen Ablauf mehr, sondern einen ABlauf der von Race-Conditions und Zufallsergebnissen geprägt wird. Mir fällt es schwer darin eine "Stabilität" zu erkennen.

[C++ Forumbot]

Dieser Thread wurde von Moderator/in Korbinian aus dem Forum Projekte in das Forum Rund um die Programmierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

[Helium]

Andere Sprachen lösen das Problem damit, dss sie einfach null aus der Sprache verbannen. Stattdessen kann man dann mit optionalen Typen arbeiten, wenn man will (vor allem lösen sie das Problem und verstecken es nicht vor dem Programmierer).

[finix]

gorgoyle schrieb:

Wenn du Interesse hast, frag mich per email.

Dein Projekt erscheint bisher ähnlich interessant wie ein mittelmäßiger Autounfall.

[gorgoyle]

Das sehe ich auch so und ich hoffe daß möglichst viele den Grund dafür finden!

Der Schuss wird nach hinten losgehen!

[Gast]

Helium schrieb:

Andere Sprachen lösen das Problem damit, dss sie einfach null aus der Sprache verbannen. Stattdessen kann man dann mit optionalen Typen arbeiten, wenn man will (vor allem lösen sie das Problem und verstecken es nicht vor dem Programmierer).

Ja, so gehört es auch. Das ganze null-Zeug ist ein riesengroßer Mist, wenn man es sich nicht aussuchen kann. In praktisch allen Mainstream-Sprachen sind Zeiger nullable, ohne dass man was dagegen machen kann.

(Löst aber nicht das Problem mit der Speicherverwaltung, um das es ursprünglich ging)

[MisterX]

Warum willst du das Konmzept in ne neue Programmiersprache packen(Die Entwicklung ist seehr aufwendig und teuer), wenn man sdie Idde in c++ verwirklichen kann(ist güstig machbar und dann ausprobierbar).

[gorgoyle]

Dieses Konzept ist nur _eines_ von vielen. Dieses allein würde für mich nicht
eine neue ProgrammierSprache rechtfertigen. Es steht aber nicht allein.

Ich versuche die Erzeugung von Null-Objekten zu automatisieren, um sie leichter zur Verfügung zu stelle.
Das vereinfacht die Bereitstelung und fördert den Gebrauch.

In C wäre es möglich einen Mechanismus in der Art der Exceptions bereitzustellen.
Weil es jedoch nicht Teil der Sprache ist, findet es auch keine Verbreitung.

Nach Rücksprache bin ich überzeugt worden, für "tote" Objekte eine eigene Klasse von
Zombie-Objekten zu erstellen, übere deren Funktion ich mir jedoch erst im Klaren werden
muss. Die Anwendung der Null-Objekte reduziert sich auf etwas, daß schön beschrieben
wird mit:

"Something for Nothing", eine Art Null-Element.

Wie diese genauer zu definieren sind, muß ich mir ebenfalls genauer überlegen, weil
in die Mengen-Lehre "nicht richtig funktioniert" wenn sie Null-Elemente enthält. Ich
muß schauen, daß ein Null-Element zu interpretieren ist als eine Art Indikator einer
"Leeren Menge". Ob das mit der Interpretation zu lösen ist, oder ob das in der
Implementierung zu berücksichtigen ist, kann ich noch nicht sagen.

Die Trennung zwischen "hat's nie gegeben" und "gabs mal aber ist jetzt tod" ist semantisch sinnvoll.

Ich muss das im Kopf erstmal durchspielen.
Das Null-Objekt-Konzept allein ist nicht ausreichend Grund für mich um eine neue
ProgrammierSprache zu begründen. Eher ein Detail. Ich fand es nur schön als Beispiel,
um ein einzelnes losgelöstes Detail vorzustellen.
Seit ein namenloser Admin seine absolute Authorität als neutrale Aufsicht verspielt hat,
fühlen sich ein paar Nachläufer ermutigt diesen Thread mit kontra-produktiven Post zu füllen.

Allein daß dieser Thread aus der Projekte-Kategorie entfernt wurde ist :xmas2: :xmas2: :xmas2:
Daß dieser Thread nicht mehr an den Posts eindeuting als Projekt zu erkennen ist, ist ebenso
Leistung der tüchtigen Admins. Ihn dann aber aus der Kategorie Projekte zu entfernen ist ... drollig!
Oder schreibt man das mit 't'? Mir ergibt sich eine ganze Kaskade von weiteren Fragen.

Der Gebrauch der Zombie-Threads ist insbesondere für Multi-Threaded-Applications sinnvoll, weil
da die linke Hand nit so genau weiß was die rechte macht.
Stell dir vor du bist ein Thread und ich bin ein Thread - und irgendwo steht ein Objekt.
Ich schlag es "tod"! Warum muß ich dir erklären daß es tod ist, wenn es dir dass noch trotz
seiner Totheit doch selber erzählen könnte, sondern stattdessen, weil du dieses nicht extra mitgeteilt
bekommst und versuchst das Objekt zu benutzen wirst dadurch sooo iritiert daß du schliesslich abstürzt
und mich und den Rest der Applikation mit! Wo bleibt denn da die Logik? Jemand sagte mal:

"Wenn die Häuser dieser Welt gebaut wären wie Computer-Programme,
dann würde ein einzelner Specht die Welt in Trümmern legen!"

Aber da wird man gleich angesprochen im Sinne von:
"Dieses Haus würde nicht sofort zusammenklappen! Dies ist ein klarer Fehler!" *zustimmendes*gemurme*
Zum debuggen wär es wohl sinnvoll den Zombie-Objekten ein anderes Verhalten zu geben, um zu gucken wo
wirkliche Fehler sind. Ich favorisiere nicht fehlerhafte Programmierung sondern fehlertolerate Systeme.
Wenn ich zum Beispiel ein Array mit 100.000 Objekten habe die zufällig früher oder später "sterben",
dann will ich gerne 1-2% tote Objekte tolerieren, und erst beim nächsten Sanity-Circle diese zu entfernen
in dem das Array neu aufgebaut wird. So kann der Betrieb weitergehen, während das neue Array erstellt
wird und in den neuen Objekt-Zustand eingebunden, während alte Zugriffe mit dem alten Array fehlerfrei
weiterarbeiten können und neue Request das neue Array benutzen. So spart man Putzarbeit und erhöht den
Durchsatz und nebenbei die Stabilität.

Die Frage nach dem Null-Objekt möchte ich gleichstellen mit den Fragen nach den Sinn von
-einer Null für die Addition
-einer Eins für die Multiplikation
-der Leeren Menge für die Mengenlehre
-dem Null-Device für File-Operationen
-etc.

Allesammt könnte man sagen: Die machen doch nichts! Also wozu?

[Walli]

Wenn Du schon mit solchen Vergleichen kommst: In der Mathematik ist eine Division durch 0 undefiniert. Da führt man auch nicht einfach irgendeine Zahl ein, damit der Taschenrechner kein NaN anzeigt und man lustig weiter rechnen kann. Und Du willst doch nicht ernsthaft behaupten, dass man die 0 und die 1 weglassen kann, bloß weil sie zufälligerweise die neutralen Elemente der Addition bzw. Multiplikation sind? Die Frage nach deren Sinn ist leicht beantwortet. Entsprechendes gilt für die leere Menge.

[gorgoyle]

lies doch bitte noch mal meinen post richtig durch.

du hast mich falsch verstanden wenn du glaubst ich wollte ernsthaft den Sinn der neutrale Element diverser Verknüpfugen in Frage stellen.

Im gegenteil! Ich wollte diese als Analogie zu dem von mir propagierten Null-Element nehmen, an dem sich einige Herren Anstoß nehmen.

[Walli]

Schon klar, was Du damit beabsichtigen wolltest. Die Analogie hinkt aber gewaltig.

[gorgoyle]

schöne Analogie!

Beim Wurzelziehen schrieb man für negative Zahlen immer die leere Menge als LösungsMenge,
weil lange lange Zeit die Wurzel aus negativen Zahlen nicht definiert war.

Aber dann führte man die Imaginäre Einheit i ein wobei i definiert ist als i²=-1

Fortan gelten Wurzeln aus negativen Zahlen als möglich nur liegt der WerteBereich
der WurzelFunktion außerhalb der Menge der Reellen Zahlen.

Man hat den defnierten Bereich also erweitert und kann seitdem damit tolle Sachen machen.

Bei der Divison duch Null scheiterete eine Einführung einer "unendlichen Einheit" ∞
weil man die Annahme vertritt, daß ∞+∞=∞ ergeben müßte.
Das führt schnell zu Widersprüchen.

Ich denke wenn man diese Annahme weglässt und eine bessere Vorstellung von der Unendlichkeit entwickelt,
(die alten Griechen hielten sogar alles größer 1000 für unendlich), dann läßt sich auch mit ∞
rechnen.

Kurz: Nur weil man etwas definiert führt ess nicht zu einer dessen Widerspruchsfreiheit und damit zu einer
unproblematischen Existenz. Daß die Null-Streams den Character eines Neutralen Elements haben sollen muß ich
wohl nochmals unterstreichen. Und der Vergleich mit der undefinierten Operation 0/x kann ich gut akzeptieren.
Man kann ebend mit Null fast alles machen aber ebend nicht alles weil es ebend die Null ist. Ich finde dies
beschreibt sehr gut die Rolle bzw. Aufgabe, die ich den Null-Objekten zu geben beabsichtigte.

[gorgoyle]

@MisterX

Ich möchte eine neue ProgrammierSprache entwickeln.
Die Null-Objekte selbst sind nicht der Grund dafür!

Das Konzept der Null-Objekte halt ich für wichtig
genug, um es vorherein gleich mitzuimplementieren.

[Helium]

Schnapp dir ne dynamische Sprache, wie z.B. Smalltalk, bau dir ein Objekt, dass auf jede Nachricht damit reagiert sich selbst zurückzugeben und du hast dein Verhalten.
Dann kannst du dir angucken wie toll das doch ist, ohne eine neue Sprache erfinden zu müssen.

... ach so, hat Objective-C nicht schon ein message eating nil?

[Konrad]

Helium schrieb:

... ach so, hat Objective-C nicht schon ein message eating nil?

Ja hat's. Alle Nachrichten die an nil gesendet werden lösen sich quasi in nichts auf bzw. geben 0, NULL, nil oder NO zurück.

[Blue-Tiger]

Deine Mathe-Analogie klappt deswegen nicht, da es in der Mathematik keine Seiteneffekte gibt. Vielleicht hab ich (& die anderen) dein Konzept nur falsch verstanden. Erklaer mal bitte, was in folgender Situation passieren soll (das Beispiel stammt von rapso):

es gibt 2 Threads, und die beiden greifen auf das gleiche Datenbankobjekt zu. Thread 1 loescht nun die Datenbank, sie wird also durch ein Null-Objekt ersetzt. Was passiert jetzt, wenn Thread 2 etwas in die Datenbank schreiben will?
Passiert gar nichts? Wird eine Exception geworfen? Oder wird ein Fehler zurueckgegeben?

Ich seh in allen 3 Faellen nichts, was "immer sinnvoll" ist, und deswegen trifft deine Idee hier auf so viel Widerstand.

In Aussnahmefaellen mag so ein Verhalten, wie du es vorschlaegst, Sinn ergeben, aber selbst dann muss es in der Hand es Programmierers liegen zu entscheiden, was bei Verwendung des Null-Objekts passiert (weil es wie gesagt je nach Situation verschiedene "beste Loesungen" geben kann). Und genau dafuer gibts wie bereits erwaehnt ja das Null-Object-Pattern: http://www.cs.oberlin.edu/~jwalker/nullObjPattern/

Du wirst hier im Forum genug "Sprachtheoretiker" finden, und dass sich die meisten so gegen die Idee des universalen Nullobjects wehren, sollte dir zu denken geben. Wenn du nicht bereit bist, deine Ideen oeffentlich hier im Forum zu diskutieren (wozu ich dir aber raten wuerde, weil du dann ein viel breiteres Publikum ansprechen kannst), dann musst du wohl mit einer anderen tollen Idee locken, als mit etwas, das universell nicht funktioniert und fuer das es ansonsten bereits ein Pattern gibt.

[Bashar]

Blue-Tiger schrieb:

Deine Mathe-Analogie klappt deswegen nicht, da es in der Mathematik keine Seiteneffekte gibt.

Sag das den Informatikern, die seit 60 Jahren ihre Wissenschaft auf der Mathematik aufbauen

es gibt 2 Threads, und die beiden greifen auf das gleiche Datenbankobjekt zu. Thread 1 loescht nun die Datenbank, sie wird also durch ein Null-Objekt ersetzt. Was passiert jetzt, wenn Thread 2 etwas in die Datenbank schreiben will?
Passiert gar nichts? Wird eine Exception geworfen? Oder wird ein Fehler zurueckgegeben?

Das muss man sich für jeden Datentyp überlegen. Unter den Beispielen war ja z.B. das Null-Device, was jeden Schreibzugriff wirkungslos verpuffen läßt und bei Lesezugriffen stets EOF liefert. Bei Prozeduren wie etwas in die DB schreiben ist ein Null-Effekt sogar normalerweise ein sinnvolles Defaultverhalten, schwieriger wird es bei Funktionen.

Ich seh in allen 3 Faellen nichts, was "immer sinnvoll" ist, und deswegen trifft deine Idee hier auf so viel Widerstand.

Genau, ich denke, es liegt auf der Hand, dass das jeweils für jeden Typ speziell festgelegt werden muss.