Technix

Wie man leicht an der zeitlichen Reihenfolge der Posts sehen kann, habe ich der aktuellen Aktivitäts-Phase mit dem Post #62 einen leichten Anschub versetzt. Das konnte ich noch, ohne daß meine Beiträge durch einen Moderator einer regelmäßigen Zensur unterlagen. Warum wurde danach eine Regel-Zensur eingeführt? Denn nichts anderes ist eine Beitrags-weise Freischaltung ja, wobei eine Kultur des Mißtrauens und der Selektion trotz aller Allen zu Gute kommenden Qualitäts-Ansprüchen grundsätzlich eine erhebliche Schwelle für einen freien Meinungs-Austausch und das Verständnis von Gleichwertigkeit darstellt.

Inwieweit für das zur Verfügung stehende Kapital überhaupt ein Managed Account sinnvoll ist, sollte auch noch geprüft werden. Die grundsätzliche Annahme, daß ein Managed Account Größenordnungs-mäßig mehr Rendite bringt als andere Anlagen läßt sich bei Betrachten gängiger Performance-Maßstäbe nämlich nicht zweifelsfrei belegen. Wenn es also um mehr als Depot-Diversifikation geht, ist das Anliegen als solches intensiv zu hinterfragen. Wenn nun noch von der ersten Liga der Verwalter abgewichen wird, wo dann wirklich zuweilen Traum-Renditen als Werbe-Argument aufgezeigt werden, sollte genau hin geschaut werden, wie diese denn erreicht werden. Das wird sehr selten ohne seriös nicht tragbare Risiken geschehen und adressiert ein Publikum, welches eigentlich nicht in der Lage ist, eine vernünftige Auswahl des Verwalters zu treffen, da es nur einseitig auf eine in irgendeiner Periode mal erreichte Rendite fixiert ist und alle anderen Kriterien vernachlässigt. Diesem Publikum stehen dann viel zu oft nicht so sehr überragende Trader als vielmehr andernorts mit andererleuts Geld schon gescheiterte hemmungslose Zocker gegenüber.

Ich hatte die Beiträge im Umfeld des Community-EA positioniert, weil ich dachte, daß die Dinge dort Software-Projekt-mäßig bisher noch nicht auf der best-möglichen Schiene laufen. Die Abtrennung ist gut, wenn das inhaltlich Nutzbare daraus auch dorthin übernommen wird. Das mit der sehr exzessiven Zerlegung der Funktionalität in viele sehr kleine Module sieht wirklich oft noch viel unübersichtlicher aus als ein vielzeiliger monolithischer Code-Block. Das hatte ich auch schon vorab zugegeben. Trotzdem ist die maximale Zerlegung nach dem derzeitig aktuellem Wissen der Software-Technologie berechtigt der state-of-the-art und stellt gerade für die modernen hoch-produktiven agilen und Test-basierten Arbeitsweisen eine notwendige Grundlage dar (ohne etwa darauf beschränkt zu sein). Damit wird insbesondere das Erstellen von zusätzlichem Code für Unit-Tests wesentlich vereinfacht, wobei ausreichender Test-Code in aller Regel ähnliche oder noch größere Ausmaße hat wie die zu testende Software selber. Module müssen so einfach sein, daß im Test eine 100 %-ige lokale Pfad-Abdeckung innerhalb des Moduls erreicht wird. Das ist in großen Monolithen mit vielen Fall-Unterscheidungen wegen der kombinatorischen Explosion der alternativen Pfade nicht mehr möglich. Ungetestete Pfade sind aber noch schlechter als gar nicht erst geschriebene Pfade, zumindest auf Ebene der kleinsten testbaren Einheiten. Eine weitere ganz wichtige moderne Arbeitsweise ist andauerndes und unaufgefordertes Refactoring, was bedeutet, daß der Code von jedem qualifiziertem Leser bei Verbesserungs-Möglichkeiten auch umgehend verbessert wird, auch in kleinen Dingen, wie z. B. schlecht gewählten Bezeichnern. Das ist bei Code, den man lokal nicht mit einem Blick übersehen kann, aber kaum möglich. Ebenso wird niemand Verantwortungs-bewußt Code ändern, der nicht durch umfassende Unit-Tests abgedeckt ist, weil er damit das gesamte Software-System beschädigen kann. Beim Navigieren wird bei der sehr starken Zerlegung meist unterschieden zwischen den ohne Weiteres im Quelltext übersehbaren kleinen Modulen und größeren Paketen/dem System im Ganzen. Da sind leistungsfähige Entwicklungs-Umgebungen mit vernünftigen grafischen Browsern gefragt. Wenn man die nur sehr eingeschränkt hat, wie z. B. innerhalb des MetaTraders, kann man sich mit gut gewählten Sub-Systemen in eigenen Verzeichnis-Strukturen, Bezeichner-Konventionen und Dokumentations-Kommentaren und einem Dokumentations-Tool helfen ... und den verbleibenden Rest mit der Hand malen, z. B. mit Visio oder Dia etc. Bei so katastrophal geschriebenen Alt-Last-Code-Blöcken, wie 'Der Wolf' sie angibt, sind Nassi-Shneiderman-Diagramme wirklich ein gutes Hilfs-Mittel. So ein Code sollte heute aber von niemandem mehr geschrieben werden, weil er nach Jahrzehnte-lang theoretisch gesichertem und vielfach in Projekten belegtem Erkenntnis-Stand der Software-Branche bekannt ist als teuer in der Wartung, demotivierend für die Entwickler, anfällig für alle Arten von Fehlern und hemmend für Neu-Entwicklungen, sowohl im Kontext der vorhandenen Software als auch beim Übergang auf eine völlig neue Version. Da die Probleme neben den objektiven Mängeln der Code-Verständlichkeit noch zusätzlich durch offenen oder latenten Ekel vor hirnrissigem Code bei den damit beschäftigten Entwicklern um ganze Größen-Ordnungen verstärkt werden, ist so ein Stil heute für Neu-Entwicklungen ein absolutes Tabu, wenn man seine Entwickler nicht absichtlich frühzeitig zum Burn-out hetzen will. Selbst kleinste If-Anweisungen können mit einem semantisch bedeutsamen Namen als Einzeiler-Funktion geschrieben werden. Das mag zwar nach Super-Overhead aussehen, hat aber den Vorteil, daß jeder auch ohne Kommentar sofort weiß, was der Autor da prüfen wollte. Als Neben-Effekt wird gleich noch eine semantische Prüfung mit dem Bezeichner geliefert. Macht dieser fachlich Sinn und ergibt ein normales Wort, wo prüft man vermutlich was Wesentliches. Fällt er eher als Aneinanderreihung vor Worten aus oder hört sich sonstwie krank an, so ist möglicherweise die Prüfung selber fragwürdig. Über Laufzeit-Verlangsamungen durch gut lesbaren Code braucht man heute in den meisten Fällen nicht wirklich nachzudenken, da gibt es viele andere Faktoren, die mehr kosten. Insbesondere kann eine falsche Komplexitäts-Klasse eines Algorithmus bei nur genug zu verarbeitenden Daten nicht durch irgendwelche Optimierungen an Implementierungs-Details ausgeglichen werden. Bei Compiler-Sprachen gilt: Jeder Code braucht nur einmal vom Computer gelsesen zu werden, aber meist viel öfter von Menschen. Daher ist alles, was dem Menschen die Arbeit erleichtert gut, richtig und wichtig. Zum ganzen Komplex des Clean Code war das empfohlene Buch Clean Code schon eine ziemlich brauchbare Quelle und ich will hier nicht das ganze Buch wiedergeben, zumal ich es im Moment nicht vor mir liegen habe. Wenn man UML-Diagramme nur am Anfang nutzt, ist man nicht sehr produktiv. In einer vernünftigen Werkzeug-Umgebung sind Zwei-Wege-Tools Pflicht, die Änderungen sowohl in Richtung UML -> Code als auch in Richtung Code -> UML propagieren. UML-Diagramme werden bei professionellen Tools auch nicht Stunden-lang für irgendeine Doku-Ablage schön-formatiert, sondern ad-hoc im Moment der Frage mit den entsprechenden Filtern aufgestellt und von dort wird unmittelbar in den Quelltext weiter geklickt. Das "gesunde Mittelmaß" gibt es bei Clean Code gerade nicht, weil es da überhaupt kein Mittelmaß gibt. Entweder ist etwas state-of-the-art oder muß sofort und ohne irgendwelche Rückfragen geändert werden, weil es dann eben auch nicht "gesund" war. Clean Code setzt nicht auf irgendwelche Bürokratien und kleinteilige Arbeits-Aufträge sondern auf die Kompetenz aller Beteiligten inkl. des Bewußtseins damit langfristig die Kosten für die Wartung um eine Größen-Ordnung zu reduzieren, indem kaum mehr teure ad-hoc-Reparaturen fällig sind oder der Code zu "verwesen" beginnt, weil sich niemand mehr um ihn kümmert, weil er zu eklig ist ("stinkt"). Zur Beschreibung potentieller Nutzungs-Möglichkeiten, wie sie von Objekten ja erst einmal mit nur geringem erforderlichem Kontext bereit gestellt werden sollten, sind Nassi-Shneiderman-Diagramme nicht geeignet. Sie können nur bereits vorgedachte Abläufe aufzeigen. Programmierung im Großen hat nicht nur mit der aktuell genutzten Aufruf-Hierarchie zu tun, sondern auch immer mit potentiellen Möglichkeiten, wo bereits fertige Objekte in neue, noch unbekannte Zusammenhänge gebracht werden. Immer wenn das nicht geht, sind die Objekte zu wenig universell angelegt und die Software hat einen Entwurfs-Schaden. Wenn dann die Modul-Struktur so abgeändert wird, daß allgemeiner nutzbare Teile von den eher sehr spezifischen abgetrennt werden, entstehen zwangsläufig feingranulare Objekt-Strukturen mit teils nur wenig neu hinzu gekommener Funktionalität von schon vorhandenem zu neu hinzugefügtem, die Anfänger in großen Klassen-Hierarchien meist sehr verwirren, die sich oft fragen, warum solche Unmengen kaum voneinander unterschiedlicher Klassen eingeführt werden. Die Beschreibung von Programm-Systemen im Großen ist nicht an Pseudo-Code als dem "Wie geht es?" interessiert, sondern an der Präsentation der potentiellen Möglichkeiten der Objekte, dem "Was geht damit?". Bei ordentlicher Bezeichnung sagt alleine der Name des Objektes für einen mit dem Anwendungs-Gebiet Vertrauten genug aus, um das Objekt und seine Methoden einsetzen zu können. Irgendwelche unerwarteten, über die Intention des gut gewählten Bezeichners hinaus gehende Dinge sind streng verboten ("Prinzip der geringsten Überrraschung", die Funktion "Tür_Öffnen" darf eben auf keiner Hierarchie-Stufe egal wie tief verborgen jemals die Funktion "Bombe_Zünden" aufrufen, es sei denn wir implementierten gerade die Klasse "Tür_mit_Sprengfalle" [die übrigens gerade darum besser mittels Interface oder Mixin gebaut würde]). Alleine schon das reine Aufzählen aller vorhandenen Objekte und ihrer Funktionalitäten nur mit ihren Bezeichnern ist bei gängigen Klassen-Bibliotheken wie in .NET, Java odr Python bei Tausenden von Objekt-Klassen und Zehntausenden Methoden nicht mehr trivial. Um diese Präsentation geht es bei der Programmierung im Großen.

Bezüglich der Erwähnung der Nassi-Shneiderman-Diagramme sage ich mal, daß der heutige (leider bei weitem noch nicht überall akzeptierte) Standard spätestens seit dem Kult-Buch von Robert C. Martin Clean Code und der darauf folgenden ganzen Clean Code Development-Bewegung eher eine sehr exzessive Zerlegung der Funktionalität in viele sehr kleine Module ist. Damit bekommt man zwar sehr große und durchaus auch wieder zur Unübersichtlichkeit neigende Ansammlungen von Modulen, aber insgesamt kann man sie besser testen, abändern, systematischer dokumentieren und einiges mehr, welches aus Zeit-, Kosten- und Stabilitäts-Sicht im Software-Prozeß wichtig ist. Sicher ist das Clean-Code-Buch schon recht extrem, aber ich teile in etwa 87 % seiner Ansichten. Ganz brachial überspitzt, soll demnach eine Funktion nur in etwa so komplex sein: function top_function(args) if condition(args) then return sub_function_for_case_true(args) else return sub_function_for_case_false(args) In dem Buch sind sehr viele gute und eher zu vermeidende Pattern zusammengefaßt. Nassi-Shneiderman-Diagramme sollten im Normalfall nicht notwendig sein, da echter Bedarf an ihnen fast immer darauf hindeutet, daß der beschreibene Code zu komplex ist, daß er sich nicht mehr selber dokumentiert. Manche Autoren sind sogar der (oft, aber nicht immer, auch zutreffenden) Ansicht, daß es keine kürzere sinnvolle Beschreibung für einen Programm-Ablauf gibt als das Programm selber und jedes zusätzlich erforderliche Dokument (insbesondere bzgl. der Programmierung im Kleinen, worauf sich Nassi-Shneiderman-Diagramme ja ausschließlich beziehen) von Übel ist. Erst bei der Zusammenstellung von Modulen und Paketen bei der Programmierung im Großen, kommt man selten - auch bei bester Qualifikation aller Beteiligten - nicht um zusätzliche Entwurfs-Materialien herum. Die dort erforderlichen Darstellungen gehen aber weit über Nassi-Shneiderman-Diagramme hinaus und sind wie die Unified Modeling Language von einer nicht trivialen eigenen Komplexität, die meist komplexere Tool-Umgebungen erfordert, um wirkliche Produktivitäts-Vorteile zu bekommen.

Aus der Sicht des Projekt-Managements laufen die Dinge suboptimal, wenn man zü früh diverse Details der letztlichen implementatorischen Realisierung durchspricht. Zuerst sollte die Rahmen-Struktur des Projektes und des Produktes festgelegt sein. So ist es z. B. ein großer Unterschied, ob man die fachlichen Dinge größtenteils vor der Implementation vorbereitet haben will und man damit eher bei einem geradlinigen Wasserfall-artigen Projekt-Modell landet oder ob man hochgradig agil operieren möchte oder ob man bezüglich bestimmter grundlegender Rahmen-Strukturen eher Wasserfall-artig und bezüglich des Ausfüllens der Rahmen-Strukturen mit Details z. B. mit dynamisch konfigurierbaren Plug-Ins eher agil arbeitet. Für den Zugriff auf die erzeugten Materialien ist zuerst einmal ein Repository zur Versionsverwaltung erforderlich, wobei sich da Git besonders anbietet. Wenn niemand einen Server bereit stellen kann, auf dem Git installiert ist (was für einen Admin eine Kleinigkeit sein sollte), tut es auch ein öffentlicher Git-Server, wie z. B. github.com. Ggf. ist ein zusätzliches Quell-Code-Review-System, wie z. B. Gerrit sinnvoll, wo die integrierenden Chef-Entwickler auf allzu großen Wildwuchs besseren Einfluß nehmen können. Fachlich sollte man sich klar dazu bekennen, wie man die Aufwände statistischer Hypothesen-Bildung und -Verifikation im Vornherein (vor der Ausprogrammierung) und das Kontrollieren im Nachhinein mit Backtests bei Vorliegen des ausprogrammierten ATS aufteilen will. Die Vorab-Analyse von Massen-Daten geht mit C/C++/Java-Programmen deutlich besser als mit spezialisierter Software für Handels-Systeme, da man damit keine Beschränkungen hat. Sind die Datensätze wirklich groß, kann man problemlos auf Cloud-Cluster, wie z. B. Amazons EC2 ausweichen, statt ewig auf einen Leistungs-schwachen Heim-PC zu warten.

Der "FXM" wollte die Million ja noch ertraden, beim Betreiber der Site RTS Capital dürfen sie die Leute gleich erstmal mitbringen. Daß dort Einlagen-Geschäft, Vermögens-Verwaltung, Introducing-Brokerage und was sonst noch alles ohne BAFin-Lizenz läuft, braucht da kaum noch zu wundern.

So sehr solche Projekte im Prinzip von der Motivation her zu begrüßen wären, so realistisch ist es, ihnen im Mittel extrem geringe Effizienz und ziemlich frühes Einschlafen zuzusprechen. Ohne auf dieses Forum oder irgendwelche Beteiligten konkret Bezug nehmen zu wollen, besteht die allgemeine Tendenz, daß durch diverse zwar Interessierte, aber wenig fachlich Qualifizierte und noch weniger ausreichend Fleißige alle möglichen Dinge sehr oft immer wieder erneut ohne rechten Fokus und ohne substantielle Fortschritte diskutiert werden, aber nur wenig und in geringer Qualität implementiert werden. Oft werden da Dinge, angefangen vom Erlernen schon zig-fach abschließend in der Literatur beschriebener grundsätzlicher Programm-Strukturen, zu scheinbar gigantischen Leistungen aufgebläht, für die vermeintlich ganze Stäbe alleine zur Planung erforderlich sind - und alle wollen steuern, ohne überhaupt über die Grund-Richtung einig zu sein, und erst recht will kaum einer rudern. Daraus resultiert meist im Vergleich mit guten Leistungs-Trägern, die manche Dinge in Stunden schaffen, die in sehr heterogenen Communities in Monaten nicht mal richtig angefangen, geschweige denn fertig werden, eine reine Zeit-Verschwendung für die wenigen kompetenten Leistungs-Träger, die das auch irgendwann einsehen und ihre anfängliche Top-Motivation einbüßen. Die Mehrheit der nicht zu den Top-Leuten gehörenden Teilnehmer verliert ihre Motivation hingegen durch zu geringen Fleiß bei der Aufnahme neuer Erkenntisse und der darum ebenso fehlenden praktischen Vertiefung, so daß am Ende alle demotiviert sind, die Guten wie die Schwachen. So löblich solche Projekte auch sein können, die meisten jemals begonnenen Open-Source-Projekte ohne einen kleinen Kern aus reinem Eigen-Bedarf ohnehin schon in der gleichen Sache Aktiven und auf die Möglichkeit später drum herum zu erbringender Dienstleistungen Fokussierten, sind von langfristiger Minimal-Aktivität oder dem Absterben vor der ersten brauchbaren Release geprägt. Daher habe ich auch ehrlich mit "Nein" gestimmt, lasse mich aber sehr gerne von meiner völligen Fehl-Einschätzung durch Übertragung allgemeiner Erkenntnisse auf dieses Projekt durch Vorlegen echter Produkte überzeugen. Bis dahin baue ich aber lieber mehr auf gesunden Realismus, wenngleich der von der Tschakka-Fraktion als plumpe Miesmache abgetan wird. Anmerkung: Tschakka funktioniert Erfahrungs-gemäß nur bei Vertiebs-nahen Leuten, fast gar nicht bei Technikern. Für eine Implementierung werden aber Techniker gebraucht.

Nachdem ich mich vor etwa 2 Jahren nach einer expliziten Einladung durch die Macher dieses Boards schon nach kurzer Zeit wegen einer Zensur-Maßnahme wegen einer unbedeutenden Minimalität und darauf folgenden Streitereien um das Urheber-Recht an meinen Artikeln hier zurück gezogen habe, mußte ich mit Bedauern feststellen, wie auch andere kompetente Autoren beschädigt wurden, wie z. B. Krümel oder jetzt gleich auch noch goso. Über seine Kritik, daß sich Leute in unserem Alter nicht von Leuten, die unsere Kinder sein könnten, wegen Kleinigkeiten oder gar Eingebildetem maßregeln lassen müssen, sollte mal ernsthaft nachgedacht werden. Ein Board lebt von seinen wenigen Top-Autoren und nicht anders herum. Wenn das Einbringen berechtigter Kritik durch Leute, die sich mit guten Artikeln gleich in Masse ausgezeichnet haben, genauso bewertet wird wie die Zoten von Dauer-Pöblern und eine scheinbare "Harmonie" nur mit rigider Administration erzeugt werden kann, ist ein Board weit vom Ideal respektvollen Austausches entfernt. Da hilft auch nicht, sich auf die formal immer anwendbare und durch den Hausherren beliebig auslegbare und ohnehin auch ohne jede Begründung jeden Adminstrations-Schritt erlaubende Haus-Ordnung zurück zu ziehen. Ein Forum ohne ausreichende Freiheit ist noch schlechter als gar keines, weil ohne Forum nur auf eine möglicherweise wünschenswerte Plattform verzichten muß, man sich als Autor bei überbordender Zensur aber andauernd selber verbiegen muß. Edit: Da paßt es ganz ins Bild, wenn man sich über andere Autoren mit Kritik lustig macht, wie z. B. hier. Nehmt einfach mal Eure User Ernst!

Passt gerade gut, denn ich war auch 'Silent Reader'. Bei mir stand im Warn-Hinweis, daß beim Schreiben das Zurücksetzen auf den alten Status erfolgt, scheine aber wohl in einer Anfänger-Gruppe (früher stand noch irgendwas Raffiniertes in einem schwarzen? Balken).

Ich merke korrigierend und entschuldigend an, daß in der Funktion readAndConvert() in einer Kommentarzeile # character data, R in basic package configuration has no special data type stehen sollte, wobei ohne die getestete Funktionalität zu mindern, bei irgendeinem Suchen/Ersetzen aus "data" ungewollt an zwei Stellen "equity" geworden ist. Habe es hier noch hinzugefügt, weil sich der Kommentar gerade auf die Kern-Frage bezog und so nicht sehr sinnreich war.

# --- configurable data -------------------------------------------------------- inputFileName <- 't:\\Oanda.in' # input file name of data file # --- function definitions ----------------------------------------------------- readAndConvert <- function(inputFileName) # read data from input file and split DateTime to Date and a string # representing time { # read data from file, assuming a tab separation, which perhaps wasn't # displayed well in the HTML output of the data sample inputData <- read.table(inputFileName, header = TRUE, sep = '\t') # extract DateTime and Balance values using english locale time settings locale <- Sys.getlocale(category = "LC_TIME") Sys.setlocale(category = 'LC_TIME', locale = 'en') dateTimes <- as.POSIXct(as.character(inputData$Date), format = '%B %d %H:%M:%S %Y') Sys.setlocale("LC_TIME", locale) equity <- NULL # split DateTime into Date (R Date data type) and Time (a simple string) equity$Date <- as.Date(dateTimes) equity$Time <- format(dateTimes, format = '%H:%M:%S') # character equity, R in basic package configuration has no special equity type # for time without date only, for date and time together exist the two types # 'POSIXct' and 'POSIXlt' and for Date only exists type 'Date' equity$Balance <- inputData$Balance # coerce to data frame equity <- data.frame(equity) rownames(equity) <- dateTimes return(equity) } filterLastQuoteOfTheDay <- function(equity) # extract the data lines which represent the last quote of a day # assumes equity already sorted by DateTime { isEOD <- vector() for ( i in 1 : nrow(equity) ) isEOD[i] <- equity$Date[i] != equity$Date[i + 1] isEOD[nrow(equity)] <- TRUE return(equity[isEOD,]) } filterLastQuoteOfTheDay.alternativeSolution <- function(equity) # same result as above but with more R tricks equity[tapply(rownames(equity), factor(equity$Date), max),] plotEquity <- function(equity, plotType = 'o') # plot the equity against the date { yMinMax <- c(min(equity$Balance) * 0.95, max(equity$Balance) * 1.05) par(bg = '#C0C0C0', mar = c(8, 6, 3, 1), mgp = c(5, 1, 0)) plot(equity$Date, equity$Balance , type = plotType, pch = '-' , ylim = yMinMax, log = 'y' , axes = FALSE , main = 'Equity', xlab = 'Date', ylab = 'Equity' , cex.main = 1.05, cex.lab = 0.85 ) box() axis(1, las = 3, at = equity$Date, labels = equity$Date) axis(2, las = 1, padj = 0.35, hadj = 0.9) } # --- run the functions -------------------------------------------------------- equity <- readAndConvert(inputFileName) equityEOD <- filterLastQuoteOfTheDay(equity) # equityEOD <- filterLastQuoteOfTheDay.alternativeSolution(equity) # plotEquity(equity) plotEquity(equityEOD, 'l')

So geht es nicht, mit dem in den Raum stellen einer Behauptung wie im Post 15 des Threads Denkmäler vs. Tauben mit einer eigenen parteilichen Stellungnahme jemanden ins Unrecht zu setzen und danach durch Schließen des Threads die dortige unmittelbare Antwort-Möglichkeit zu nehmen. Das erinnert an Gutsherrenart und ist kein guter Stil im Umgang, insbesondere mit einer sehr fleißigen Ex-Moderatoren-Kollegin. Inwieweit Dinge private bzw. geheime Angelegenheiten der Betroffenen selbst sind, kann jeder Einzelne von diesen selbst entscheiden. Wenn Krümel es für nötig hielt, das öffentlich darzustellen, ist es vielleicht ein Zeichen, daß sie diese nach einem vorigen Disput noch nicht befriedigend gelöst sah. Wenn whipsaw dann wenig moderat nachsetzt, zeigt es doch eher, daß da nach wie vor Klärungsbedarf besteht. Wenn es vorher zu dem gesamten Komplex zwischen allen "Offiziellen" Schriftverkehr gab und die aktuellen Postings erkennen lassen, daß dabei kein ausreichender Konsens erzielt wurde, ist das Abschneiden der Beschäftigung damit, nicht das richtige Mittel. Ungeklärte Differenzen schwelen weiter und hinterlassen bei anderen Unbeteiligten selbst dann ein schlechtes Gefühl einer wenig transparenten Atmosphäre, wenn einer der Beteiligten stillschweigend, resigniert oder diplomatisch nachgibt. Darüber hinaus lebt ein Forum von seinen Autoren, insbesondere den verdienten, nicht von den "Offiziellen", die hier und da mal MODERIEREND eingreifen können, aber nicht mit Regelmäßigkeit andere Meinungen abschneiden sollten. Diese Anmerkung hat auch nichts mit der Dauer der Board-Zugehörigkeit eines Members zu tun, sondern mit üblichen Gepflogenheiten der Höflichkeit und Achtung der geäußerten Meinung eines Anderen. Darüber hinaus hieß der Board-Bereich "Speaker's Corner" und ehe man gerade dort mit der Zensur-Schere anfängt, sollte mal über den Begriff "Speaker's Corner" nachgedacht werden. Weiterhin teile ich nicht die Ansicht, daß sich einfache Board-Mitglieder aus board-politischen Überlegungen heraushalten sollten und das Recht haben, eine "heile Welt" konsumieren zu können, sondern sehe sie vielmehr in der Pflicht, die maximale Integrität einer Plattform auch zu ihrer eigenen Herzensangelegenheit zu machen und dabei keineswegs auf "Obrigkeiten" zu vertrauen.

@ whipsaw Statt noch einmal nachzusetzten in der Art "Basta" hätte ein wenig mehr Feinfühligkeit auch nichts geschadet. Egal wie vermeintlich blumig oder theatralisch jemand schreibt, so hat er sich sowohl bei seinen Inhalten, seiner Wortwahl und beim versteckten Appell etwas gedacht. Jede Aussage beinhaltet wenigstens 4 Komponenten: eine Aussage zur Sache, eine zu sich selbst, eine zum gegenseitigen Verhältnis und eine Handlungs-Aufforderung. Selbst wenn die Sachaussage völlig zufriedenstellend beantwortet wird, können die anderen drei Komponenten trotzdem weit genug daneben sein, daß sie das Verhältnis der Beiteiligten dauerhaft beeinträchtigen. Das kann einerseits durch gedankenloses Rumpoltern wie beim sprichwörtlichen Elephanten im Porzellanladen geschehen, dann kann man es entschuldigen, aber es darf erwartet werden, danach in sich zu gehen, um es nicht andauernd zu wiederholen. Im anderen Fall, wenn man eine richtige Sachaussage als Träger-Botschaft nutzt, um bewußt (oder aller Wahrscheinlichkeit abzusehen) zu verletzen oder vorhandene Verletzungen nicht wenigstens zu heilen zu versuchen, ist das einfach nur unfaire rabulistische Rhetorik. Ich habe schon Meinungen vom Typ "Na ja die Frauen eben" gehört, die hochgradig unzutreffend sind, insbesondere wenn da mal so einfach nebenbei neben dem völlig grundlos zum Nachteil aufgebauschten Frau-Sein auch gleich mal durch die restliche Lebenserfahrung begründete Position pauschal mit abgesprochen wird.

Ich bedanke mich bei whipsaw für die netten Worte. Die geäußerte Ansicht, daß man nur Gast sei und sich daher mit Einschränkungen der Meinungsfreiheit abfinden müsse, ist besonders bedauerlich, wenn man bedenkt, daß sie von einem Menschen geäußert wird, der das Privileg hatte, in den westlichen Bundesländern von Geburt an, seine Meinung ohne Gefahr übermäßiger Pressionen äußern zu können. Ich für meinen Teil habe in der Ex-DDR dafür im Zuchthaus gesessen und sehe Angriffe auf Bürgerrechte kein wenig entspannt. Darüber hinaus halte ich Posts, die weitgehend die richtigen Worte benutzen, einen Sachverhalt genau so zu beschreiben, wie der Autor es gemeint hat und nicht beliebig große Deutungs-Spielräume für Mißverständisse eröffnen, eher für besonders gelungen als für verfehlt. Wenn die gleichen Leute, die woanders, wo ich übrigens zu den durchaus beliebten Autoren gehöre, schon mit ihrem Mobbing nicht weit gekommen sind, glauben es hier nachholen müssen, werde ich dieses Board nicht zum Polemisieren mißbrauchen, sondern mich eben nur noch selten zu etwas äußern. Die User brauchen ein konkretes Board eher weniger, die Boards brauchen kompetente Autoren schon. Zu diesen gehören Leute, deren wichtigster fortgesetzter stets inhaltlich ähnlicher Beitrag darin besteht, aufzuzählen, was sie alles schon seit Jahren nicht können und auch zukünftig nicht ändern wollen, eher nicht. Wenn schon mit unfairen persönlichen Angriffen begonnen wird, merke ich gerne an, daß ich auch ohne Ignore-Funktion die Beiträge zwei woanders besonders miteinander harmonierender Mobber in der Regel gar nicht lese, aber das was ich lese, schon für die fachliche Abstinenz ausreicht.

@ Mythos Mir ist nicht entgangen, daß das schon der 2. Post ist, in dem Du einen schlechten Inhalt alleine an der Länge eines Posts festmachen möchtest und meinst, mich zurechtweisen zu müssen. Ich gehe davon aus, daß Du gut programmieren kannst und darauf auch mit recht stolz sein kannst, bloß können das Andere auch. Ausgehend von den Trading-Kenntnissen und der Lebenserfahrung werde ich mich unzutreffenden Ratschlägen aber eher weniger anschließen. Eine ehrliches - immer noch als nicht akzeptabel eingestuftes - Eingreifen durch die Mods ist immer noch besser, als Deine Zurechtweisungen. Und wenn gemeint wird, daß man alles akzeptieren muß, frage doch mal genauer nach den Beweggründen, warum ein außergewöhnlich brilliant schreibendes Mitglied schon verprellt wurde.