Suche "Programmier-Sprachen-Theoretiker"

[gorgoyle]

Gegenstand dieses Threads ist das Finden eines oder mehrerer begabter Theoretiker, um die Sprache theoretisch abzusichern bzw. einige Felder sogar regelrecht zu erforschen. Und da kommt ein hochgeschätzter Admin an um mir aber insbesondere wohl anderen mitzuteilen, weil ihm das ganze nicht gefällt, seine Authorität dafür zu mißbrauchen, um mein Unterfangen in Mißkredit zu bringen. Ich weiß nicht ob hierfür nicht der Ausdruck Kompetenzüberschreitung anzubringen ist und wenn nicht warum nicht? Ich hab hier freundlich um Helfer gebeten und werde ziemlich schlecht behandelt. Der ganze OT-Mist der hier steht bringt mir nichts gutes und ich hoffe dem Admin selbst noch mehr! Warum ich einen klareren Ton angeschnitten habe sollte jedem klar sein, der sich anguckt für was der Thread ist und was für Posts hinzukamen .. "nicht konstruktiv" ist die mildere Kategorie!

Meine Design-Philosophie sei interessant? Nun für mich respektable Personen haben mir große Zuversicht in meinen Überlegungen und meinen Verständnis der Materie zugesichert.

"Anders ist nicht immer besser, aber besser ist immer anders!" - right, Jonathan!

Dem zurfolge muß etwas als notwendige Bedingung anders sein um besser sein zu können.
Dass ich neue Wege gehen möchte, ist nach Aussage eines Admins schlimm, weil darauf auch noch welche hörten.
Warum habt ihr nicht mich angesprochen? Das Null-Objekt-Konzept ist nur eines und nicht mal das spektakulärste!
Wie findet ihr denn die Idee die Stream-Operatoren operator<<() und operator>>() von L-Bind auf R-Bind zu setzen?
Das bedeutet, daß die Anweisung cout<<aString; übersetzt wird in aString<<(cout); Dann muss das KnowHow für all die Klassen nicht in der Stream-Klasse geschrieben werden, sondern eine beliebige Klasse lernt mit Streams umzugehen.
Kleiner Unterschied - grosse Wirkung .. aber nicht revolutionär! Wegen solcher Kleinigkeiten würd ich nicht eine neue ProgrammierSprache entwickeln wollen.

Für weitere Post bitte nur Topic. Ich möchte hier nicht alle Konzepte erklären. Wer Interesse hat melde sich bitte per email

mfg gorgoyle

[finix]

Wie in aller Welt stellst du dir vor auch nur einen Hauch von Interesse an deiner Sprache zu generieren wenn du sie nicht einmal vorstellst?

[gorgoyle]

oh das ist doch einfach ..
da sagt einer er hätte sich was schickes ausgedacht und bittet um anfragen.
und wenn einer per email anfragt dann erzählt er ihm genaueres aber wird auch fragen stellen.
ic sehe da kein problem. Die anderen Projekte sind wesentlich diffuser in der Beschreibung.

Wenn du Interesse hast, frag mich per email.

[Gast]

gorgoyle schrieb:

Gegenstand dieses Threads ist das Finden eines oder mehrerer begabter Theoretiker, um die Sprache theoretisch abzusichern bzw. einige Felder sogar regelrecht zu erforschen.

Du glaubst die hier zu finden, wenn du hier nichtmal die geringste Kritik zulässt? Du musst die Leute davon überzeugen, dass dein Konzept interessant ist. Wenn du das nicht schaffst, kannst du auch niemanden finden.

[W0lf]

Wurden aus diesem Thread einige Posts gelöscht, oder hat rapso tatsächlich nur einen Beitrag dazu geschrieben?
(Ich frage, weil die Reaktion vermuten lässt, dass er sich seitenweise darüber ausgelassen hat, anstatt nur einen Beitrag zu verfassen)

[Korbinian]

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

[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.