Auf dieser Seite werden Abschnitte halbmonatlich automatisch archiviert, deren jüngster Beitrag mehr als 80 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 6 Abschnitte.

Archiv

2004 bis 2006 2007 und 2008 ab 2009

Wie wird ein Archiv angelegt?

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 7 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

Fehler bei Vorlage (Vorlage:Autoarchiv-Erledigt): Der Wert des Parameters Zeigen wurde im Namensraum "Diskussion" mit "Nein" angegeben.

gudn tach!
die aenderungen [2] habe ich zum grossen teil revertiert, weil sie unbelegt waren. allerdings habe ich die loeschung des abschnittes

Außerdem wird die Verwendung von Programmierrichtlinien aus Gründen der Wartbarkeit und Fehleridentifizierung mehr als in anderen Sprachen angeraten. Demgegenüber ist der Stand vieler Lehrbücher und Lehrveranstaltungen veraltet. Lehrinhalte stimmen oft nicht mit der Realität existierender Compiler überein.

nicht revertiert (der abschnitt ist also weiterhin geloescht), weil nicht belegt wurde, dass das in C++ wirklich grossartig anders ist, als in anderen sprachen. bei z.b. java, python und perl sind auch viele handbuecher veraltet. und zu sauberem code wird auch in allen sprachen immer und immer wieder geraten. -- seth 22:57, 25. Apr. 2012 (CEST)Beantworten

Belegen kann ich dass auch nur mit meiner Erfahrung. Aber Fakt ist, dass Compiler "anderer Sprachen" wesentlich bessere Fehlermeldungen werfen (können). Insbesondere sobald man Templates verwendet sind die Ausgaben des C++ Compilers im Fehlerfall keine Hilfe mehr. C++ ist auch die einzige mir bekannte Sprache, für die es einen Parser für die Fehlermeldungen des Compilers gibt [3] ... --TT (Diskussion) 11:46, 26. Apr. 2012 (CEST)Beantworten

gudn tach!

fehlermeldungen sind fuer anfaenger immer kryptisch, in so ziemlicher jeder sprache. je fortgeschrittener man ist, desto eher versteht man die meldungen. das trifft auch schon auf so eigentlich simple sprachen wie LaTeX zu (fuer die LaTeX-fehlermeldungen gibt's uebrigens auch parser). und in jeder sprache gibt's meldungen, die einen in die irre fuehren, in einigen sprachen z.b. falschgesetzte klammern.

templates, die man ja durchaus als eine eigene sprache (tmp) ansehen kann, sind tatsaechlich etwas, dass die ganze sache noch etwas komplizierter macht. c++template-fehlermeldungen sind standardmaessig schlecht lesbar, das ist richtig, und mittels stlfilt kann man sie etwas aufhuebschen. es ist jedoch quark, zu sagen, dass z.b. die gcc-template-fehlermeldungen einem keine hilfe waeren.

tmp ist uebrigens nicht nur in c++ vorhanden, sondern gibt es in aehnlicher form auch in einigen anderen sprachen.

aber so kommen wir vermutlich nicht weiter. was man braeuchte, waeren serioese sprach-vergleiche. -- seth 00:44, 28. Apr. 2012 (CEST)Beantworten

Da gibt's was altes in meinem BNR. Wurde damals im ANR gelöscht, ich glaube wegen TF bzw. willkürlicher Auswahl der Kriterien, müsste aber nachschauen.

Allgemeine Aussagen zu Fehlermeldungen sind ausserdem schwierig, weil sich hier einzelne C++ Compiler stark unterscheiden. gcc und msvc sind da z.B. sehr stark unterschiedlich. Wenn man aber eine Weile mit dem Compiler gearbeitet hat, lernt man die Macken kennen und weiss dann mit der Zeit, was mit einer bestimmten Meldung wirklich gemeint ist. --PaterMcFly Diskussion ^Beiträge 08:49, 28. Apr. 2012 (CEST)Beantworten

Das Buch C++ Programmierung für Anfänger beschreibt die Grundlagen Programmierung mit C++ leicht verständlich auf wenigen Seiten. Für Anfänger scheint es mir sehr geeignet zu sein. Bisher finden sich hier ja eigentlich keine Bücher für Anfänger. Das sollte man ändern.

Dann aber nicht aus einem BoD-Verlag. Siehe auch WP:LIT. Curtis Newton ↯ 19:06, 7. Mai 2012 (CEST)Beantworten

Ich habe den Abschnitt gelöscht, da es sich um unbelegte Behauptungen handelte, also Theoriefindung. --Sunks (Diskussion) 18:15, 22. Mai 2012 (CEST)Beantworten

Deine Löschungen erscheinen mir zum Großteil sinnvoll. Einzelne Punkte so in den Vordergrund zu stellen, und das ohne Belege, ist in der Tat TF (auch mit dem Aufwand der Implementierung, da gibt es noch ganz andere Gründe). Und die Erläuterungen zum #include sind wahrlich entbehrlich. Aber wieso hast du Erscheinungsjahr und Implementierungen in der Infobox entfernt? --Chricho ¹ 18:32, 22. Mai 2012 (CEST)Beantworten

Erscheinungsjahr und Implementierung: Aus ganz ähnlichen Gründen. Siehe meine Edit-Kommentare. Falls weiterer Diskussionsbedarf besteht, würde ich dich bitten, einen (oder mehrere) neue Abschnitte auf dieser Diskussionsseite dazu zu beginnen. --Sunks (Diskussion) 15:05, 23. Mai 2012 (CEST)Beantworten

Ich denke, es passt so. --Chricho ¹ 17:43, 23. Mai 2012 (CEST)Beantworten

Ich halte die Liste unter Paradigmen in der Infobox nicht für sinnvoll, denn eine Programmiersprache kann ein so genanntes Programmierparadigma mit mehr oder weniger vielen Sprachmitteln unterstützen, aber ab welchem Grad der Unterstützung soll das betreffende Paradigma in die Liste aufgenommen werden? Wie soll man den Grad der Unterstützung messen? Die Entscheidung für oder gegen eine Aufnahme ist unweigerlich Ermessenssache, also POV. Ein Beispiel ist die funktionale Programmierung. Es gibt in C++ sicher Elemente, die sich der funktionalen Programmierung zuordnen lassen, andererseits gibt es aber nicht einmal "reine Funktionen". Im Artikeltext kann man auf diese Details eingehen. Das ist informativ und sinnvoll. Aber einfach nur einen Begriff ohne Kontext in eine Liste zu klatschen (oder wegzulassen) entspricht nicht dem Grundgedanken einer Enzyklopädie. Bestimmt gibt es Dinge, die sich sinnvoll in einer Tabelle darstellen lassen (beispielsweise die Normen), die Programmierparadigmen gehören aber nicht dazu. (Mit der Typisierung verhält es sich ähnlich.) Deswegen bin ich dafür, diese beiden Listen die Liste Paradigmen aus der Infobox zu entfernen. --Sunks (Diskussion) 20:59, 25. Mai 2012 (CEST)Beantworten

Kann ich nicht unterschreiben, C++ ist nun einmal imperativ und objektorientiert, das kann man nicht leugnen. In anderen Artikeln zu Programmiersprachen sind die Paradigmen auch angegeben. Was setzt du bitte an der Typisierungsbox aus? —Gorlingor (Diskussion) 21:42, 25. Mai 2012 (CEST)Beantworten

Ich habe meinen Standpunkt relativ ausführlich erläutert, und deshalb bitte ich dich, auf meine Argumente einzugehen. "ist nun einmal" und "das kann man nicht leugnen" sind keine Gegenargumente. Beachte bitte die Schwierigkeit, die in der Definition der so genannten Paradigmen liegt. Im Artikel imperative Programmierung kannst du nachlesen, dass imperative Programmierung manchmal mit prozeduraler Programmierung gleichgesetzt wird, manchmal aber auch nicht. Was ist es denn nun? Und selbst zur objektorientierten Programmierung kann man anmerken, dass sie im Unterschied zu Sprachen wie Smalltalk nur unvollkommen in C++ integriert ist. Das Problem wird dadurch verschärft, dass es unterschiedliche Definitionen zur Objektorientierung gibt. Siehe beispielsweise What is „Object-Oriented Programming“: "Object-oriented programming is programming using inheritance.", oder Einführung Objektorientierung: "Objektorientierung ist ein Ansatz aus der Softwareentwicklung, der die Zusammenfassung von Daten und den dazugehörigen Funktionen in Klassen von Realweltobjekten unterstützt.", oder Introduction: What is Object-Oriented Programming: "OOP, defined in the purest sense, is implemented by sending messages to objects."

Man kann die Frage "wird Paradigma x unterstützt oder nicht" eben nicht einfach mit ja oder nein beantworten. Das ist das Problem. Und in der Tabelle fehlt der Kontext.

"In anderen Artikeln sind die Paradigmen auch angegeben" ist übrigens kein Argument, denn in anderen Artikeln kann es ja genauso fragwürdig sein.

Da ich mich zur Typisierungsbox bisher noch nicht ausführlicher geäußert habe, und anscheinend Einwände bestehen, nehme ich die Liste zur Typisierung zunächst wieder in den Artikel. Die Diskussion dazu können wir ein anderes mal weiterführen. Hier soll es zunächst nur um die Paradigmen gehen. --Sunks (Diskussion) 16:56, 26. Mai 2012 (CEST)Beantworten

C++ erfüllt beide deiner genannten Definitionen von Objektorientierung …

Aber ich verstehe schon, worauf du hinaus willst. Man kann es ruhig in den Fließtext schreiben, aber nicht einfach die Box entfernen. Im Fließtext steht übrigens immer noch, dass die objektorientierte Programmierung unterstützt wird. —Gorlingor (Diskussion) 17:02, 26. Mai 2012 (CEST)Beantworten

Es erfüllt nicht unbedingt die dritte Definition (nachträglich hinzugefügt). Doch, die Liste "Paradigmen" in der Infobox muss aus den genannten Gründen entfernt werden. Und den Fließtext müssen wir auch in Angriff nehmen, da gebe ich dir Recht. --Sunks (Diskussion) 17:07, 26. Mai 2012 (CEST)Beantworten

Ergänzt du nun die Informationen im Fließtext? —Gorlingor (Diskussion) 14:47, 3. Jun. 2012 (CEST)Beantworten

Ich finde, der ganze Abschnitt "Eigenschaften" müsste mal überarbeitet werden. Kannst dich gerne selber daran versuchen. --Sunks (Diskussion) 16:20, 3. Jun. 2012 (CEST)Beantworten

Könnte man nicht einfach „funktional“ streichen? Dass es multiparadigmatisch ist und das OO, gen., str. und proz. Programmierung mit einschließt, ist doch wohl unbestritten. --Chricho ¹ ³ 17:03, 3. Jun. 2012 (CEST)Beantworten

Das ist eben alles andere als unbestritten. Bitte lies dir die gesamte Diskussion in diesem Abschnitt durch, damit ich nicht alles wiederholen muss. Das ganze Thema ist viel komplizierter, als es auf den ersten Blick scheint. --Sunks (Diskussion) 03:52, 4. Jun. 2012 (CEST)Beantworten

Zum gesamten Thema siehe auch → falsches Dilemma. --Sunks (Diskussion) 04:00, 4. Jun. 2012 (CEST)Beantworten

Ich sehe darin, zumindest im Falle von C++ kein Problem, das man nicht lösen könnte. Man könnte festlegen, dass eine explizite Unterstützung wesentlicher Voraussetzungen eines Paradigmas seitens des Sprachkerns, Standardbibliothek oder Vergleichbarem für eine Nennung in der Infobox maßgeblich ist, man sich auf explizit darauf ausgelegte Sprachfeatures beschränkt, und es nicht darum geht, dass sie völlig dem jeweiligen Paradigma folgen (Definition 3 wäre ausgeschlossen) oder nur einen Softwareentwicklungsansatz erlauben (Definition 2 wäre ausgeschlossen, damit wäre etwa auch C objektorientiert zu nennen). Funktionale Programierung wäre zu streichen, weil C++ keinerlei Features anbietet, die darauf ausgelegt sind, Programmteile nur aus Funktionen aufzubauen.

Ich sehe da eigentlich kein Problem, das man lösen müsste. Tabellen können eingesetzt werden, solange sie sinnvoll sind und ihren Zweck erfüllen, wie z.B. bei den Normen (ISO/IEC 14882:1998 usw.), und wenn sie das nicht tun, dann lässt man sie eben weg. Jede "Festlegung" die man bezüglich der Aufnahme in die Tabelle treffen würde, wäre willkürlich und von der persönlichen Sichtweise abhängig, also POV. Aber wie gesagt: Das Thema lässt sich eigentlich sehr gut ohne Tabellen darstellen. --Sunks (Diskussion) 21:47, 4. Jun. 2012 (CEST)Beantworten

Nun, die Infoboxen sind aber egtl. auch nicht dafür gedacht, nur eine Minimaldosis absolut uninteressanter Attribute aufzunehmen. Natürlich sehe ich die Problematik. Da das vmtl. auf die Artikel zu so gut wie allen Programmiersprachen zutrifft und es wohl bislang flächendeckend so gehandhabt wurde, größzügig Attribute – nach bestimmten Maßstäben oder auch einfach so – einzutragen: Wie wäre es mit einer Diskussion Wikipedia Diskussion:Redaktion Informatik? --Chricho ¹ ³ 00:44, 8. Jun. 2012 (CEST)Beantworten

Ich möchte widersprechen, dass es unzulässig ist, ein Kriterium für die Infoboxen festzulegen. Es ist nun einmal so, dass Wörter unterschiedlich gebraucht werden. Nehmen wir einmal geographische Artikel als Beispiel, dort ist es eindeutiger, dass so etwas in der Wikipedia möglich sein muss: Landesname, Einwohnerzahl (insb. bei Städten↔Metropolregionen), Hauptstadt, Staatsform, Regierungssystem, überall da muss festgelegt werden, nach welchen Kriterien man vorgeht, und gerade das ist das, was sinnvollerweise in eine Infobox gehört. Noch etwas: Sinn einer Infobox ist übrigens auch nicht, darzustellen, was man im Fließtext nicht gut darstellen kann – dafür sind sonstige Tabellen und Listen da, darum geht es an dieser Stelle nicht – eine Infobox soll einen schnellen Blick auf gewisse grundlegende, strukturierte Informationen liefern (womöglich sogar maschinell verarbeitet werden). Ich denke also: Infoboxen sind sinnvoll und wenn es denn machbar ist, ist es besser, einheitliche Kriterien festzulegen, als auf sie zu verzichten. --Chricho ¹ ³ 00:57, 8. Jun. 2012 (CEST)Beantworten

Es geht um etwas anderes. Nimm mal diesen Artikel → Aachen. Die Liste der unter Stadtgliederung angegebenen Stadtbezirke ist eindeutig und vollständig. Da gibt es nichts zu deuteln. Das mit den Paradigmen ist aber Interpretationssache. --Sunks (Diskussion) 02:57, 11. Jun. 2012 (CEST)Beantworten

Ich habe nicht behauptet, dass es bei allen Infoboxen Möglichkeiten zur Willkür gäbe. Nimm eben z. B. die, die Regierungssystem aufführen. Ich bezweifle, dass dir die Infoboxen in C, Perl, PHP oder Java viel besser gefallen. Die alle zu leeren, ohne vorher mal ein paar Gedanken gemeinschaftlich sich gemacht zu haben, halte ich für wenig sinnvoll, die Infobox ist im Moment völlig nutzlos, und ich denke, man sollte es zumindest in Erwägung ziehen, bei manchen Einträgen Maßstäbe festzulegen. Wärst du vllt. bereit, deinen Standpunkt in der Redaktionsdiskussion einmal darzulegen? Sonst würde ich dort bald einmal eine Diskussion versuchen anzustoßen, aber du hast das ja schließlich auch hier initiiert. --Chricho ¹ ³ 03:26, 11. Jun. 2012 (CEST)Beantworten

Du hast das Beispiel mit den Geografieartikeln gebracht, und ich habe dir gezeigt, warum es sich dort anders verhält. Die Handhabung in den Geografie-Artikeln ist nicht auf die bei Programmiersprachen übertragbar.

Ich habe nicht vor, die Infoboxen von C, Perl, PHP oder Java zu bearbeiten. Eine Diskussion in einer größeren Runde ist für mich also uninteressant. Ich habe im Moment auch leider nicht die Zeit dafür. Vielleicht ein anderes Mal. --Sunks (Diskussion) 05:24, 11. Jun. 2012 (CEST)Beantworten

Wie gesagt, der Artikel Aachen braucht auch weder Regierungssystem, noch Hauptstadt, noch ist es dort sinnvoll, von irgendeiner Monopolregion zu sprechen. --Chricho ¹ ³ 11:04, 11. Jun. 2012 (CEST)Beantworten

Zu den von dir erwähnten "einheitlichen Kriterien": Die einheitlichen Kriterien sind möglicherweise eine der Wurzeln des Übels, denn die Materie Programmiersprachen ist zu komplex und inhomogen um sie in einfache, einheitliche Kriterien zu fassen. Nehmen wir beispielsweise das so genannte "Erscheinungsjahr". Es lässt sich für C++ nicht sinnvoll bestimmen, für andere Programmiersprachen aber schon. Für C++ könnte man hingegen die Verabschiedungszeitpunkte der jeweiligen Normen angeben (dann unter einem anderen Eintrag, nicht unter "Erscheinungsdatum"), die meisten Programmiersprachen sind aber gar nicht genormt. Mit anderen Worten, man kommt nicht um Einzelfallbetrachtungen herum. --Sunks (Diskussion) 17:22, 15. Jun. 2012 (CEST)Beantworten

Ich werde die eine oder andere Sache an Infoboxen anderer Programmiersprachen doch ändern. Das wird in erster Linie Unbelegtes betreffen. --Sunks (Diskussion) 03:41, 27. Jun. 2012 (CEST)Beantworten

Ich habe die Infobox wieder hineingegeben so wie sie vor der Löschung von Sunks drinnen war. Bitte um Diskussion vor Änderung. Bitte auch darzustellen, warum C++ anders als alle anderen Programmiersprachen gehandhabt werden soll. Bitte auch zu bedenken dass Projekte wie Wikipedia:Wikidata auf Infoboxen angewiesen sind. --Sebastian.Dietrich ✉ 18:14, 27. Jun. 2012 (CEST)Beantworten

Die Diskussion hat bereits stattgefunden. Wenn du eine Änderung möchtest, kannst du eine neue Diskussion starten. Aber bitte erst ausdiskutieren, dann ändern. --Sunks (Diskussion) 17:28, 28. Jun. 2012 (CEST)Beantworten

Nein dem ist nicht so. Du hast die Diskussion "beendet" indem du gesagt hast, dass du es mal so machst, wie du es vorgeschlagen hast. Niemand anderer hat sich davor dafür ausgesprochen. --Sebastian.Dietrich ✉ 17:36, 28. Jun. 2012 (CEST)Beantworten

Da kann ich dir leider nicht folgen. Es ist der Diskussionsstand. --Sunks (Diskussion) 19:02, 28. Jun. 2012 (CEST)Beantworten

Es scheint mir so, als gäbe es einen Dissens bezüglich der Typisierung von C++ zu geben (so um [4]). Um das nicht in einen Edit-War ausarten zu lassen, sollten wir uns mal einigen. Wie in Starke Typisierung beschrieben, ist Typisierung nichts absolutes, bestenfalls etwas vergleichbares. Mal paar Argumente für jede Seite:

C++ ist stark/streng typisiert:

• Keine implizite Konvertierung zwischen Klassen (ob es das irgendwo gibt?)
• Keine implizite void* -> xyz*-Konvertierung
• eindeutig unterschiedliche Datentypen, Klassen etc
• Keine implizite Konversion von Klassenpointern virtuell abgeleiteter in ihre Basisklassen (blöd zu beschreiben, aber in etwa so: Derived* xyz = dynamic_cast<Derived*> abc; // where decltype(abc) == Base*)

C++ ist schwach typisiert:

• Implizite Konversion z.B. zwischen Zahlwertvariablen, C-Strings, Zahl-Arrays... (im Extremfall double -> char)
• Implizite Konversion von Klassen, die auf bestimmte Weise verwandt sind (sogar unter Datenverlust, Derived -> Base)
• Implizite Konversion von Klassenpointern, die auf bestimmte Weise verwandt sind (Derived* -> Base*)
• Ergänzung: Der Messer ^{meckern? - Bew} 19:33, 8. Jun. 2012 (CEST): Nach Bereitstellung der passenden Operatoren ist eine implizite Konvertierung zwischen so ziemlich allem möglichBeantworten

Wie gesagt, es ist schwer zu bestimmen, was C++ jetzt eigentlich ist. Ich persönlich würde für stark plädieren, aber, wie gesagt, nur persönlich. Nach Argumenten ist es beides und keins :-) Was sagt ihr? --Der Messer ^{meckern? - Bew} 18:56, 7. Jun. 2012 (CEST)Beantworten

Da C++ die Eigenschaften von C erbt, ist es a fortiori nur schwach in Sachen Typen. Vielleicht sollte man die Begriffe im Text stärker herausarbeiten. -- ZZ (Diskussion) 19:07, 7. Jun. 2012 (CEST)Beantworten

C++ erlaubt implizite Konvertierung zwischen Klassen, und zwischen Klassen und elementaren Datentypen, auf nahezu beliebige Weise, die Konvertierungen müssen nur jeweils implementiert werden. Sind elementare Datentypen beteiligt, können sogar mehrere implizite Konvertierungen infolge ausgeführt werden. Es gibt eine große Vielzahl an Typunterschieden (Basisklassen, Qualifier und aufwändigere Konvertierungen), die beim Aufruf (potenziell überladener) Funktionen erlaubt sind. Auch Konvertierungen zwischen elementaren Datentypen finden mitunter unter Datenverlust statt (allerhand Typen → bool, größerer Ganzzahltyp → kleiner Ganzzahltyp, Fließkomma → Ganzzahl, Ganzzahl → Fließkomma). Ebenfalls ist char *str = "abc"; erlaubt – unter Verlust des const-Qualifiers. Schlussendlich bietet C++ Konstrukte wie unions, direkten Zugriff über char-Pointer und reinterpret_cast, die das Typsystem umgehen. Ich denke, das ist recht eindeutig und es hatte das nur übereifrig jemand geändert gehabt. --Chricho ¹ ³ 19:23, 7. Jun. 2012 (CEST)Beantworten

Wobei der letzte Punkt eher Unsicherheit zu nennen ist, habe das ergänzt. --Chricho ¹ ³ 19:27, 7. Jun. 2012 (CEST)Beantworten

Ich sehe da die gleichen Probleme wie bei starker/schwacher Typisierung. Mal abgesehen davon, dass die beiden Konzepte so stark miteinander zusammenhängen, dass eine getrennte Darstellung fraglich erscheint. --Sunks (Diskussion) 21:37, 7. Jun. 2012 (CEST)Beantworten

@Der Messer: Wie in starke Typisierung beschrieben, ist Typisierung nichts absolutes. Genau. In die Infobox zu schreiben, C++ sei stark oder schwach typisiert, ist genauso, als würde man in die Infobox zum Eiffelturm schreiben, der Turm sei groß. Oder eben klein, je nachdem. Mit anderen Worten: Der Eintrag ist so nicht sinnvoll. Wie ich schon geschrieben habe, halte ich Tabellen in manchen Fällen für eine sinnvolle Ergänzung zu Artikeln; hier brauchen wir aber Fließtext. Das gleiche gilt für "Typsicherheit". In der Newsgroup comp.lang.c++.moderated hat sich übrigens Alexandrescu in einem Beitrag genau dazu geäußert, nämlich (sinngemäß) dass Typsicherheit keine binäre, sondern eine Art kontinuierliche Eigenschaft sei.

Insgesamt halte ich das Thema Typisierung in C++ für ein komplexes Thema, dem man wahrscheinlich einen eigenen Artikel widmen könnte. Oder auch ein ganzes Buch.

@ZZ: Richtig, die Lücken, die C aufreißt, schließt C++ nicht. Mit einer signifikanten Ausnahme: void* lässt sich, anders als in C, nicht jedem Zeiger zuweisen. Darüber hinaus könnte man argumentieren, dass ein "moderner Programmierstil" die von C geerbten Nachteile vermeidet, so dass es in realen C++-Programmen diesbezüglich effektiv deutlich weniger Probleme gibt. (So vermeidet beispielsweise unique_ptr<T> viele derartige Probleme.) Die Begriffe im Text stärker herauszuarbeiten findet jedenfalls meine volle Zustimmung (s.o.). --Sunks (Diskussion) 21:34, 7. Jun. 2012 (CEST)Beantworten

Un nu? Einfach rausnehmen, da es unmöglich ist, das zu definieren? --Der Messer ^{meckern? - Bew} 19:42, 13. Jun. 2012 (CEST)Beantworten

Die Einträge schwach und unsicher würde ich in jedem Fall rausnehmen. Aber was machen wir mit statisch? Es gibt ja auch dynamische Typinformationen. --Sunks (Diskussion) 21:27, 13. Jun. 2012 (CEST)Beantworten

Gemäß → statische Typisierung ist nicht entscheidbar, ob C++ als statisch oder dynamisch typisiert zu bezeichnen ist. Also alles raus. --Sunks (Diskussion) 17:35, 14. Jun. 2012 (CEST)Beantworten

Die Bezeichnungen schwach und unsicher sind weit verbreitet. Es ist auch nicht unmöglich, das zu definieren, es bleiben nur Grauzonen. Deswegen schlage ich eine Erweiterung des oben beschriebenen Ansatzes vor: 1. Quellen finden und zitieren, 2. sagen, was es heißen soll, 3. wie Sunks sagte, darauf hinweisen, dass es um die Sprache geht, es aber sehr wohl Programmierstile bzw. Programmierdisziplin gibt, die eingesetzt werden. In anderen Worten, man kann auch in einer schwach getypten Sprache typsicher programmieren. Nur will man das nicht immer. -- ZZ (Diskussion) 13:44, 16. Jun. 2012 (CEST)Beantworten

Die Einträge in der Tabelle nehme ich dann erst mal raus. --Sunks (Diskussion) 07:36, 27. Jun. 2012 (CEST)Beantworten

Versuch einer Zusammenfassung: C++ ist sowohl stark als auch schwach, sowohl statisch als auch dynamisch typisiert (jeweils unterschiedliche Teile). So wie Fassade des Empire State Buildings (in jeweils unterschiedlichen Teilen) aus Glas, Kalkstein, Granit besteht plädiere ich dafür alle Typisierungen von C++ aufzunehmen.--Sebastian.Dietrich ✉ 19:30, 29. Jun. 2012 (CEST)Beantworten

Wegen Bearbeitungskrieg wurde der Artikel in einer Vorkriegsversion für zwei Tage vollgesperrt. Bitte hier die Diskussion sachlich austragen, ggf. eine dritte Meinung einholen und der nächste Revertieren (nach Ablauf der Sperre) wird temporär zum Lesen verdammt. Sollte ein vorzeitiger Kompromiss/Konsens gefunden worden sein, bitte bei mir oder dem nächsten Admin melden. Danke. --Kuebi [∩ · Δ] 19:16, 28. Jun. 2012 (CEST)Beantworten

Auch wenn ich halbwegs aktiv bei dem Artikel hier bin, wollte ich fragen (ist mir gerade unklar, zu viele Edits), weshalb die Sperrung erfolgt -- wegen der Typisierungssache? Grüße, --Der Messer ^{meckern? - Bew} 19:54, 28. Jun. 2012 (CEST)Beantworten

Siehe nächster Abschnitt. Ich habe die Infobox wiederhergestellt und um Diskussion darüber gebeten. Wurde von Sunks reverted ("wurde bereits ausdiskuttiert"). Nachdem das nicht stimmte (siehe nächster Abschnitt) hab ich das in die disk geschrieben und reverted. Sunks hat dann reverted und Vandalismus gemeldet. --Sebastian.Dietrich ✉ 20:35, 28. Jun. 2012 (CEST)Beantworten

Bestandsaufnahme:

• C++ ist eine Programmiersprache - warum keine Infobox:Programmiersprache? Weil am 27.6. von Sunks entfernt ([5]). lt. Diskussion waren dafür: 0 Personen (nichtmal Sunks hat das angekündigt/erwähnt/vorgeschlagen). C++ ist somit die einzige Programmiersprache in der Wikipedia, die keine Infobox:Programmiersprache hat.
• C++ beeinflusste andere Programmiersprachen und wurde von anderen Programmiersprachen beeinflusst - warum steht das nicht in der Infobox? Weil am 24.5. von Sunks ohne Diskussion darüber entfernt ([6])
• C++ folgt Paradigmen - warum steht das nicht in der Infobox? Weil am 3.6. von Sunks "lt. Diskussion" entfernt ([7]). lt. Diskussion waren dafür: 1 Person (Sunks), dagegen waren 2 Personen (Benutzer:Chricho, Benutzer:Gorlingor)
• C++ unterstützt verschiedene Arten von Typisierungen - warum steht das nicht in der Infobox? Weil am 27.6. von Sunks "siehe Diskussion" entfernt ([8]). lt. Diskussion waren dafür: 0 Personen (nichtmal Sunks hat das angekündigt/erwähnt/vorgeschlagen). Einzig Benutzer:Der Messer hat die Frage in den Raum gestellt, ob man das löschen sollte, aber niemand hat sich dafür oder dagegen ausgesprochen.
• C++ wurde hauptsächlich von Bjarne Stroustrup entwickelt - warum steht das nicht in der Infobox? Weil am 24.5. von Sunks ohne Diskussion darüber entfernt ([9])
• C++ erschien irgendwann - wann (zumindest Anfang der 80er) steht nicht in der Infobox? Weil am 21.5. von Sunks ohne Diskussion darüber entfernt ([10])
• C++ wird durch C++ Builder etc. implementiert - warum steht das nicht in der Infobox? Weil am 22.5. von Sunks ohne Diskussion darüber entfernt ([11])

Tolle Leistung. Siehe auch Sunks "Verbesserungen" in C-Sharp, COMAL, COBOL, Cω, Ceylon (Programmiersprache), Basic Combined Programming Language, Alef (Programmiersprache), ACUCOBOL, ABAP, A+ (Programmiersprache), Ada (Programmiersprache), D (Programmiersprache), PHP, Java (Programmiersprache) --Sebastian.Dietrich ✉ 20:26, 28. Jun. 2012 (CEST)Beantworten

Anstatt zu versuchen mir Formfehler nachzuweisen, solltest du Argumente zur Sache bringen. Nur so kommen wir weiter. Niemandes Meinung soll hier unter den Teppich gekehrt werden. Allerdings sollte sich jeder, der sich hier beteiligt, in die Diskussion einlesen, damit wir nicht bei jedem neuen Diskutanten komplett von vorn anfangen müssen. Wichtig ist auch, auf die Argumente der anderen Diskutanten einzugehen und nicht gebetsmühlenartig den eigenen Standpunkt zu wiederholen.

Anders als du es darstellst, wurden fast alle Themen, die du oben erwähnst, hier auf die eine oder andere Art besprochen, allerdings wurden den Punkten "Erscheinungsjahr" und "Entwickler" noch keine eigenen Abschnitte gewidmet, deshalb schlage ich für die weitere Diskussion vor, damit zu beginnen (s.u.). --Sunks (Diskussion) 00:45, 29. Jun. 2012 (CEST)Beantworten

Formfehler ist was anderes. Klar soll sich jeder in Diskussionen einlesen (darum auch oben die Zusammenfassung der Pro- und Contra- Stimmen). Das gilt aber auch für dich. Wenn bei Diskussionen klar herauskommt, dass etwas bleibt, dann solltest du es nicht löschen. Nochmals eine Zusammenfassung für Dich:

• Infobox lassen/löschen - wurde nicht diskuttiert
• Beeinflusste/wurde beeinflust lassen/löschen - wurde nicht diskuttiert
• Paradigmen lassen/löschen - wurde diskuttiert +1 für löschen, +2 für lassen
• Typisierungen lassen/löschen - wurde nicht diskuttiert (nur die Frage wurde gestellt)
• Entwickler & Erscheinungsjahr - wurde nicht diskuttiert (s.u.)
• Implementierungen - wurde nicht diskuttiert

Ich trage jetzt die fehlenden Diskussionen unten nach --Sebastian.Dietrich ✉ 08:35, 29. Jun. 2012 (CEST)Beantworten

Doch, mit Ausnahme der Vorlage Infobox und Entwickler/Erscheinungsjahr wurde alles schon einmal auf die eine oder andere Art aufgegriffen. Es spricht allerdings nichts dagegen, die Themen noch zu vertiefen. Ich bin also damit einverstanden, dass du unten einige neue Abschnitte einführst. Was die Vorlage Infobox betrifft: Ich bin nicht dagegen, aber warum nicht etwas verbessern, falls es möglich ist? Typisierung: Doch, wurde sogar verhältnismäßig ausführlich diskutiert. Ich halte es in diesem Fall nicht für sinnvoll, noch einen neuen Abschnitt dafür zu beginnen. Den letzten Kommentar von ZZ, bevor ich geschrieben habe, dass ich den Eintrag entferne, sehe ich als Zustimmung, die Darstellung auf den Fließtext zu verlagern. Vielleicht äußert er sich selber noch einmal dazu.

Auch bei dem Abschnitt zu den Paradigmen halte ich es nicht für sinnvoll, noch einen neuen Abschnitt anzufangen. Übrigens werden Diskussionen zu Inhalten nicht per Abstimmung entschieden. Entscheidend ist also nicht die reine Willensäußerung, sondern die Begründung. --Sunks (Diskussion) 17:03, 29. Jun. 2012 (CEST)Beantworten

Es geht mir nicht um den Inhalt der einzelnen Felder, sondern dass diese nicht gelöscht werden, nur weil diese nicht 100% klar sind. Wenn man z.B. nicht exakt wissen würde, wann C++ erstmals der Öffentlichkeit präsentiert wurde (1985), so sollte das drinnen stehen, was man dazu weiss (in den 1980er Jahren). Infoboxbefüllung ist keine exakte Wissenschaft. --Sebastian.Dietrich ✉ 10:51, 30. Jun. 2012 (CEST)Beantworten

Ich möchte nur gerne auf diese Abstimmung verweisen. Curtis Newton ↯ 10:44, 30. Jun. 2012 (CEST)Beantworten

Wie alle Programmiersprachen verdient auch C++ eine Infobox. Infoboxen sind ein wichtiger Bestandteil der Wikipedia, sie helfen Lesern gleichartige Informationen an der gleichen Stelle zu finden. Sie sind für behinderte Menschen (v.a. Blinde&Sehbehinderte) extrem hilfreich, um sich in der Wikipedia zurechtzufinden. Sie sind Voraussetzung für Software (siehe z.B. Wikipedia:Wikidata) um Daten lesen/abgleichen/verstehen zu können --Sebastian.Dietrich ✉ 08:44, 29. Jun. 2012 (CEST)Beantworten

Was nicht sinnvoll ist, bleibt draußen. Das gilt auch für Infoboxen. Allerdings steht die Box gar nicht grundsätzlich zur Disposition, deshalb sehe ich hier keinen Diskussionsbedarf. --Sunks (Diskussion) 17:29, 29. Jun. 2012 (CEST)Beantworten

Wunderbar, dann bleibt die Infobox Software also weiter drinnen und du ersetzt sie nicht durch eine Wikitable.  Ok --Sebastian.Dietrich ✉ 19:31, 29. Jun. 2012 (CEST)Beantworten

Selbstverständlich lassen, wie auch bei anderen Programmiersprachen. Beeinflussungen sind einfach erkennbar, durch Literatur etc. belegbar. --Sebastian.Dietrich ✉ 19:31, 29. Jun. 2012 (CEST)Beantworten

Nein, im Gegenteil, "Beeinflussungen", wie du es nennst, sind manchmal nicht einfach erkennbar. Soll ich ein Beispiel nennen? Ich tu's einfach: Die Beeinflussung von C durch Java ist so grundlegend, dass sie einen eigenen Abschnitt im Artikel C verdient hätte. Um diesen Zusammenhang zu erkennen, muss man sich eingehend mit dem Thema beschäftigen. In der gesamten Wikipedia findet sich aber nicht der kleinste Hinweis darauf. --Sunks (Diskussion) 09:27, 30. Jun. 2012 (CEST)Beantworten

Verstehe jetzt deine Argumentation nicht. Du erkennst also an, dass es Beeinflussungen zwischen Programmiersprachen gibt, forderst dafür sogar eigene Abschnitte ein, möchtest diese aber nicht in der Infobox erwähnen? Mein Standpunkt: Alles was Allgemeinwissen (d.h. in dem Fall auf der Uni/FH in Einführungsveranstaltungen gelehrt wird) ist bzw. belegt werden kann soll rein. Egal wie schwer diese selbst im einzelnen nachvollziehbar sind. --Sebastian.Dietrich ✉ 10:29, 30. Jun. 2012 (CEST)Beantworten

Hier das was Stroustrup dazu sagt [12] Seite 12: "However, only C, Simula, Algol68, and in one case BCPL left noticeable traces in C++ as released in 1985. Simula gave classes, Algol68 operator overloading (§3.3.3), references (§3.3.4), and the ability to declare variables anywhere in a block (§3.3.1), and BCPL gave // comments (§3.3.1)." --Sebastian.Dietrich ✉ 11:08, 30. Jun. 2012 (CEST)Beantworten

Also von Beeinflussungen sind einfach erkennbar sind wir jetzt bei Egal wie schwer diese selbst im einzelnen nachvollziehbar sind gelandet?

Mein Standpunkt: Was hat der Leser davon, wenn ich (z.B.) in eine Tabelle schreibe "Die Programmiersprache C wurde beeinflusst durch Java."? Hier fehlt ganz einfach der Zusammenhang. Interessant zu wissen ist doch, in welcher Hinsicht die Sprache beeinflusst wurde. Wir schreiben hier eine Enzyklopädie. --Sunks (Diskussion) 16:16, 2. Jul. 2012 (CEST)Beantworten

Wurde bereits oben (siehe #Infobox - Paradigmen) diskuttiert +1 für löschen, +2 für lassen (Kommentar von Sebastian.Dietrich)

Inhalte werden nicht per zahlenmäßiger Präsenz der Diskutanten entschieden. Bitte hierzu keinen neuen Abschnitt beginnen. Bei weiterem Diskussionsbedarf den Abschnitt von oben bitte hierhin verschieben. --Sunks (Diskussion) 17:29, 29. Jun. 2012 (CEST)Beantworten

Ähhh wie meinst du das? Es gibt eine Diskussion, 2 sind für Lösung A, einer für Lösung B, und du erkennst dass das Diskussionsergebnis B wäre? --Sebastian.Dietrich ✉ 19:31, 29. Jun. 2012 (CEST)Beantworten

Lies dies. --Sunks (Diskussion) 09:27, 30. Jun. 2012 (CEST)Beantworten

Kenne ich, passt hier aber nicht - du hast ja an der Abstimmung teilgenommen. Das Ergebnis war nicht in deinem Sinne, du machst die Änderung trotzdem, und merkst an, dass kein weiterer Diskussionsbedarf besteht (weil du der Meinung bist, dass deine Begründungen die besseren sind).--Sebastian.Dietrich ✉ 10:22, 30. Jun. 2012 (CEST)Beantworten

Da kann ich dir im Moment leider nicht folgen. An welcher Abstimmung habe ich deiner Meinung nach teilgenommen? Kannst du einen Difflink angeben? --Sunks (Diskussion) 16:16, 2. Jul. 2012 (CEST)Beantworten

Inhalt wurde oben (siehe #Typisierung diskuttiert, noch nicht obs gelöscht werden soll. --Sebastian.Dietrich ✉ 08:46, 29. Jun. 2012 (CEST)Beantworten

Bitte hierzu keinen neuen Abschnitt beginnen. Bei weiterem Diskussionsbedarf den Abschnitt von oben bitte hierhin verschieben. --Sunks (Diskussion) 17:29, 29. Jun. 2012 (CEST)Beantworten

Wunderbar, dann brauchen wir das also deiner Meinung nach nicht diskuttieren - der Block zu Typisierungen kommt also wieder rein - mit dem Inhalt aus der Diskussion von oben. --Sebastian.Dietrich ✉ 19:31, 29. Jun. 2012 (CEST)Beantworten

Bevor wir zu dem Thema weiterdiskutieren, müssen wir uns darüber einig werden, wo. Du hast jetzt an zwei Stellen etwas ergänzt. Das ist nun wirklich unübersichtlich. Wir können den ganzen Abschnitt Typisierung, wie ich bereits vorgeschlagen habe, hierher kopieren. Wir können aber auch in diesem Abschnitt den Laden dicht machen und oben weiter diskutieren. Mir ist es egal. Wo machen wir also weiter? --Sunks (Diskussion) 09:27, 30. Jun. 2012 (CEST)Beantworten

oben - hier haben wir uns geeinigt, dass der Block reinkommt, oben einigen wir uns darauf was in den Block reinkommt.  Ok --Sebastian.Dietrich ✉ 10:14, 30. Jun. 2012 (CEST)Beantworten

Nein, wir haben uns nicht darauf geeinigt, dass der Block reinkommt. Das lässt sich nicht unabhängig von der Sinnhaftigkeit der Inhalte entscheiden. Deshalb bitte oben weiterdiskutieren. --Sunks (Diskussion) 16:16, 2. Jul. 2012 (CEST)Beantworten

Selbstverständlich lassen, wie auch bei anderen Programmiersprachen. Alle relevanten erwähnen (relevant nach den WP Kriterien), das sind eh nur eine Handvoll. --Sebastian.Dietrich ✉ 19:31, 29. Jun. 2012 (CEST)Beantworten

Ich bin dagegen. Siehe Abschnitt Abschnitt "Kritik am Sprachdesign". --Sunks (Diskussion) 09:27, 30. Jun. 2012 (CEST)Beantworten

Dort verweist Du auf dein Kommentar beim Löschen - dieses war "was wichtig oder unwichtig ist, ist POV". Deine Kritik richtet sich also nicht gegen die Auflistung der Implementierungen, sondern gegen das Wort "wichtige". Es ist also eine allgemeine Kritik an der Darstellung der Infobox - bitte die dort abzugeben.

Nochmal: Was spricht dagegen alle relevanten zu erwähnen (relevant nach den WP Kriterien), das sind eh nur eine Handvoll. --Sebastian.Dietrich ✉ 10:30, 30. Jun. 2012 (CEST)Beantworten

Das ist in etwa vergleichbar mit Themenkreisen, die in Wikipedia nicht erwünscht sind, da Wikipedia-Autoren über die Bestandteile entschieden haben. In der Wikipedia sollen aber objektivierbare Informationen dargestellt werden. Die Frage ist also, wie ein Thema von überprüfbaren, verlässlichen Informationsquellen „da draußen in der Welt“ gesehen wird. Ich mache folgenden Vorschlag: Wenn auf eine Darstellung von C++-Compilern Wert gelegt wird, dann soll so eine Zusammenstellung nach Vollständigkeit streben. Aufgrund der Menge käme dann aber eventuell eher eine "Liste von C++-Compilern" in Frage. Ausgangspunkt könnte diese Liste sein. --Sunks (Diskussion) 16:16, 2. Jul. 2012 (CEST)Beantworten

Ein Erscheinungsjahr lässt sich bei C++ nicht bestimmen. Deshalb ist dieser Eintrag nicht sinnvoll. --Sunks (Diskussion) 00:45, 29. Jun. 2012 (CEST)Beantworten

Erscheinungsjahr ist das Jahr an dem ein Ding erstmals in der Öffentlichkeit erschienen ist. Im Artikel steht "1985 erschien die erste Version von C++". Also ist entweder dieser Satz falsch, oder muss 1985 als Erscheinungsjahr auch in die Infobox. Stroustrup dazu: "I started work on what became C++ in 1979. The initial version was called "C with Classes". The first version of C++ was used internally in AT&T in August 1983. The name "C++" was used late that year. The first commercial implementation was released October 1985 at the same time as the publication of the 1st edition of The C++ Programming Language."[13] Erscheinungsjahr ist also lt. Stroustrup 1985, davor war alles "internally used". --Sebastian.Dietrich ✉ 10:40, 30. Jun. 2012 (CEST)Beantworten

Anderes Paper [14]: "...book that defined C++ in October 1985" (Seite 1), "..C++ as released in 1985" (Seite 12), "commercial release of C++ in 1985" (Seite 40)

Ja, der Satz ist falsch. Es ist richtig, dass der erste kommerzielle Compiler in dem Jahr herauskam, aber das als Erscheinungsdatum von C++ danach festzulegen, wäre Willkür. Mein Vorschlag: Eine Zeitleiste o.ä. in Form einer Tabelle anlegen, in der Beginn der Entwicklung, erster Compiler, erster kommerzieller Compiler, ISO-Norm usw. aufgeführt werden. Das ist auch informativer. --Sunks (Diskussion) 16:16, 2. Jul. 2012 (CEST)Beantworten

Es gibt hunderte von Personen, die an C++ mitentwickelt haben. Wer kennt sie alle? --Sunks (Diskussion) 00:45, 29. Jun. 2012 (CEST)Beantworten

Es reichen die maßgeblichen Beteiligten - siehe dazu Vorlage:Infobox_Programmiersprache/Doku#Parameter

In der Literatur wird fast überall ausschließlich Stroustrup erwähnt - auch im ersten Buch zu C++ (C++ Primer, Preface), detto C++ Primer Plus, Teach yourself C++, A Brief History Of Computing, Mastering C++ --Sebastian.Dietrich ✉ 09:05, 29. Jun. 2012 (CEST)Beantworten

Es gibt unzählige maßgeblich Beteiligte.^[1] --Sunks (Diskussion) 17:29, 29. Jun. 2012 (CEST)Beantworten

Nix davon ist vor 1992. Zu diesem Zeitpunkt war die Sprache schon längst etabliert und hat sich nur mehr in Kleinigkeiten (verglichen zu dem was vorher da war) verändert. Keiner der "unzähligen" Beteiligten wird irgendwo in der Literatur erwähnt, keiner ist somit maßgeblich. --Sebastian.Dietrich ✉ 19:31, 29. Jun. 2012 (CEST)Beantworten

Im Gegenteil, die Sprache hat sich seitdem stark geändert.^[1] --Sunks (Diskussion) 09:27, 30. Jun. 2012 (CEST)Beantworten

Sicher nicht im Vergleich zu dem was vorher da war - dann wäre C++ nicht mehr wiedererkennbar und diese "maßgeblichen Entwickler" wären in jedem C++ Standardwerk erwähnt. Was wir haben ist 85% so wie vor 1992, 10% Änderungen, 5% Erweiterungen. Wenn Du Literatur findest, die andere Leute als Stroustrup als maßgebliche Schöpfer von C++ erwähnen, dann rein mit diesen Leuten. Ich kenne nur Bücher, die ausschließlich Stroustrup als Entwickler von C++ belegen. --Sebastian.Dietrich ✉ 09:58, 30. Jun. 2012 (CEST)Beantworten

Woher hast du denn die Zahlen 85%, 10%, 5%? Eine überprüfbare, verlässliche Informationsquelle, die andere maßgebliche Entwickler als Stroustrup von C++ auflistet, habe ich jetzt schon mehrfach angegeben. Wenn es nach der Anzahl der Änderungsvorschläge ginge, würde ich sagen, Google hat C++ entwickelt.^[1] --Sunks (Diskussion) 16:16, 2. Jul. 2012 (CEST)Beantworten

1. ↑ ^{a b c} [1]

Ich empfehle, inhaltlich auf einen frühen Zustand (etwa Anfang Mai) zurückzugehen und von einer über Jahre hinweg bewährten Basis aus jede der Einflüsterungen von Sunks zu einer Löschung kritisch zu überprüfen.

• Das schließt nicht aus, dass die eine oder andere Änderung einmal sinnvoll sein kann; unter dem Stichwort „Schrotschussmethode“ werde ich unten erklären, warum.

Sunks fiel vor einigen Tagen damit auf, im 30-Sekunden-Takt in einer Vandalismus gleichkommenden Art serienmäßig Artikel zu verstümmeln. Dabei waren die Löschungen absolut unberechtigt; unabhängig vom Sachverhalt wurde jeweils das Universal-Totschlag-Argument „unbelegt“ angegeben. Einige Kostproben:

• ACUCOBOL – absurd; ACUCOBOL ist ein Dialekt von Cobol und natürlich ist dies beeinflusst.
• ABAP – absurd; ABAP ist nichts anderes als „Cobol für SAP“ und stammt aus einer Zeit, als der Core der SAP-Software zu 100 % in Cobol geschrieben war. (diff)
• PL/I – absurd; PL/I war der Versuch, die Vorteile der Anfang der 1960er Jahre vorhandenen Hochsprachen zu verbinden; darunter Cobol. (diff) – Grace Hopper hatte sich auch etwas von ihrem eigenen FLOW-MATIC inspirieren lassen.
• C hanebüchener Unsinn – erstaunlich, dass ([???]Kernighan und) Ritchie stehenbleiben durften.
• Disku dazu wurde geführt auf Java (Programmiersprache).

Unter den Artikel- oder Disku-Beiträgen von Sunks kann ich nichts finden, das eine Sachkunde belegen würde und konstruktiv irgendetwas aufbauen würde. Alle seine Beiträge zielen auf die Löschung von Artikelbestandteilen ab, völlig egal ob diese wesentlich wären oder nicht. Schon beim Filtern seiner Beiträge zum ANR gucke ich weitaus überwiegend auf rote Zahlen; grün wird es nur mal durch allgemeinsprachliche Stil-Verbesserung oder Einfügung eines (erfolglosen) LA.

• Dabei bedient er sich aus einem Baukasten von Standard-Begründungen, die sich auf jedes Themengebiet von ägyptischen Ausgrabungen über Diesellokomotiven, Sumpfhühnern oder Shakespeare-Stücke anwenden ließen. In der Diskussion spiegelt er jeweils die Argumentation des Gegenübers oder nur das zuletzt genannte Weblink oder die Artikel-Passage wider, erkennbar ohne wirklich zu wissen worum es geht.
• Sobald es dann in der Diskussion konkret wird, offenbart sich selbstbewusstes Auftreten kombiniert mit völliger Ahnungslosigkeit – bekanntlich ein bewährtes Rezept.
• Diese Taktik ist auch als Schrotschussmethode gebräuchlich; als Cold Reading und Barnum-Effekt analog angewendet im Kontext persönlicher Beziehungen. Gemeinsam ist, dass hier Sachkunde und höheres Wissen vorgetäuscht wird, während tatsächlich nur der Diskussion eine vage Ahnung vom Sachverhalt entnommen und gespiegelt wird. Die komplexen Verhältnisse bringen es mit sich, dass man dabei gelegentlich auch Zufallstreffer landet; bei uns eine wirklich nicht ganz exakt formulierte Aussage, eine Nebensächlichkeit oder anderes. Die Gesprächspartner sind beeindruckt ob der scheinbaren Kompetenz und geben um des lieben Friedens Willen nach.
• Ein lustiges Beispiel dazu ist in diesem Artikel die Löschung von Stroustrup als Entwickler mit der abenteuerlichen Begründung, „Es gibt hunderte von Personen, die an C++ mitentwickelt haben. Wer kennt sie alle?“
  • Niemand auf der Welt hatte bisher den Ruhm von Stroustrup bestritten, mit Ausnahme von Sunks, gestützt auf sein übernatürliches Wissen.
  • Es ist völlig klar, dass Stroustrup der Entwickler ist.
  • Die „hunderte von Personen“ gab es dann auch. Etliche Jahre später, als es um die Entwicklung der Compiler ging; sie praxistauglich zu machen, die Standardbibliotheken zu schreiben und diese Software fehlerfrei zu auszuarbeiten.
  • Im Vorwort zur ersten Auflage erwähnt Stroustrup eine Handvoll von Personen, die durch kritisches Hinterfragen und Anregungen, Vorschläge und Ideen zur Entwicklung der Sprache beigetragen hätten. Niemand ist jemals in Erscheinung getreten mit dem Anspruch, er sei der Co-Autor und Mit-Entwickler der Programmiersprache C++.
• Mysteriös auch, warum der Bezug zu C gestrichen wurde; mit dem Referenzierungs-Dereferenzierungs-Gewürge hatte C++ vom syntaktisch kompatiblen C (subset) einen der größten Nachteile geerbt.
  • Stroustrup selbst gibt in der Historical Note (3^rd ed.) einige Einflüsse bekannt – so nennt er Simula67 oder dass die exceptions aus Ada und ML stammen würden; gar die Notation der // aus Algol68 zusätzlich zum C-Kommentar.
  • Auch Smalltalk als erste Programmiersprache, in der in größerem Umfang reale Anwendungen mit Objektorientierung geschrieben wurden, hat so ziemlich alles beeinflusst, was in den 1980er und 1990ern mit OOP um die Ecke kam – mal mehr, mal weniger.
  • Die Sprachdefinition war in der Fassung von 1987 abgeschlossen und von Stroustrup selbst 1990 der Standardisierung durch ANSI und ISO vorgelegt worden. Seitdem ist an der Sprache selbst nichts Nennenswertes mehr verändert worden; Änderungen im ISO-Prozess betrafen die Standard-Bibliotheken und Erweiterungen um neue Standard-Funktionen, Klassendefinitionen etc.
• Sunks ist erkennbar nicht aus eigener externer Sachkunde tätig, sondern reflektiert bestenfalls, was er in anderen Artikeln der Wikipedia oder im jeweils zuletzt vorgetragenen Weblink findet: „muss man sich eingehend mit dem Thema beschäftigen. In der gesamten Wikipedia findet sich aber nicht der kleinste Hinweis darauf.“
  • Die Notation entstammt C, wurde 1:1 kompatibel nach C++ übertragen, und von dort unter Streichung der Referenzierungs-Dereferenzierung und des Präprozessors durch Java übernommen. – In Artikel und Infobox zu Java war aber niemals eine direkte Beziehung C→Java behauptet worden; in der Tat findet sich die C-Notation aber auch in Java, was die Infobox zu C als Großvater-Generation auch korrekt darstellt. – Der Trick ist: Man müsste sich in der Materie auskennen, und das Resultat in die Wikipedia hineinschreiben. Sunks beherrscht die in Rede stehenden Sprachen überhaupt nicht, sondern verwertet allenfalls grad gegoogelte Aussagenbröckchen aus der Sekundärliteratur.
  • Diese fachliche Basis auf dem Gebiet der Programmiersprachen ist viel zu dünn, um derart massive und unqualifizierte Kastrationen der Artikel durchzudrücken.

Ich frage mich, wo hier die versteckte Kamera ist.

Schönes Wochenende allerseits --PerfektesChaos 11:17, 30. Jun. 2012 (CEST)Beantworten

Interessant herausgearbeitet. Allerdings habe ich nach kurzem Überfliegen der Beiträge von Sunks den Eindruck, dass du dich in der Einschätzung ein bisschen weit aus dem Fenster lehnst. Auch bei Stichproben der Diskussionen hatte ich den Eindruck, dass aus Unmut über die Löschungen noch weitere Positionen gegen Sunks ins Spiel gebracht werden, die nicht so eindeutig sind. Meine Meinung dazu ist: Wikipedia ist ein freies Projekt von Freiwilligen. Es gibt deshalb keine Pflicht, Experte zu sein, Zweifelhaftes vor dem Löschen zu diskutieren – aber auch keine Belegpflicht. Alle scheinbaren "Pflichten" sind (bis auf den lizenrechtlichen Rahmen) Konventionen, die zu guter Zusammenarbeit und Artikelqualität führen sollen. Diese Konventionen besagen aber auch, dass im Zweifel die Belege derjenige bringen muss, der die Information im Artikel haben will. Was in diesem Themengebiet nun Allgemeinwissen ist und was nicht, kann nicht ein WP-Autor entscheiden (dass C++ oder Java eine Programmiersprache ist, ließe sich übrigens leicht bequellen).

Ich habe die Diskussion nicht genau genug gelesen, um Anhaltspunkte zu erkennen, dass die Beiträge von Sunks allein auf Verwertung von Google-Suchen basieren. Unzweifelhaft unpassend finde ich aber seine Position, bei "unklarer Quellenlage" Informationen zu löschen. Es geht offenbar auch um Punkte, die sowieso nicht Kern der Wissenschaft sind: Welche Sprache wie viel Einfluss auf andere Sprachen hatte, wird meist im laxen Plauderton der Kapiteleinleitungen in Lehrbüchern diskutiert, oder in Nebenbemerkungen. Das ist aber auch offensichtlich. Deshalb muss man diesen Eintrag nicht aus der Infobox streichen.

Aber die Meinung von Sunks, dass Fließtext vorzuziehen ist (wenn ich das richtig zugeordnet habe), teile ich auch. Wenn also die Typsierung als stark und/oder schwach angegeben wird oder ALGOL als Einfluss aufgezählt wird, erwarte ich dazu auch Text im Artikel. --Zahnradzacken (Diskussion) 14:14, 30. Jun. 2012 (CEST)Beantworten

Dass Sunks keine Ahnung haben soll, ist mir aus dem Diskussions- und Bearbeitungsverlauf nicht ersichtlich. Bitte nicht zurücksetzen, außerhalb der Infobox fanden sehr viele Verbesserungen statt. Seine Bearbeitungen haben zu einem sehr großen Teil in der Tat eine Berechtigung, etwa, dass es wirklich verschiedene Auffassungen von (starker|statischer|sicherer) Typisierung gibt, die je nachdem einen anderen Infoboxeintrag implizieren würden. Dass in der Tat die Liste der Beeinflussten keinen Anspruch auf Vollständigkeit haben kann, dass in der Tat der Erscheinungsjahreintrag unterschiedliche Optionen lässt. Dies ist jedoch ein grundsätzliches Problem solcher Infoboxen, das man, meiner Meinnug nach, wie ich auch schon einmal gesagt habe, nicht dadurch lösen sollte, dass man nur noch völlig nutzlose Informationen stehen lässt, statt dessen sollte man festlegen, nach welchen Kriterien die Einträge auszuwählen sind (die Probleme gibt es auch in ganz anderen Gebieten – ich brachte das Beispiel Geographie, zählt man bei einer Einwohnerzahl die Metropolregion? Kann Englisch als Amtssprache der USA bezeichnet werden? Wie sind Staatsform und Regierungssystem zu bezeichnen?). Notwendig ist meiner Meinung nach daher eine Grundsatzdiskussion, wie man damit umgehen soll und am besten, wenn es Zustimmung dafür gibt, die Festlegung von Kriterien für die Infoboxen. Es scheint mir unausweichlich, wenn man denn Infoboxen haben möchte, was bislang die gängige Praxis war.

Unangenehm überrascht bin ich allerdings davon, dass er nun auch in anderen Artikeln ohne weitere Rücksprache in anderen Artikeln Informationen aus Infoboxen löscht. Hier teilte er mir mit, dass er keine Grundsatzdiskussion führen wolle, weil er lediglich an diesem Artikel interessiert sei und etwa im Artikel C (Programmiersprache) nichts ändern wolle, obwohl er das zu diesem Zeitpunkt bereits getan hatte. Und nun macht er auch noch bei anderen Artikeln weiter. Seine jüngsten, von PerfektesChaos aufgeführten Änderungen wurden zum Glück revertiert. --Chricho ¹ ³ 14:41, 30. Jun. 2012 (CEST)Beantworten

Bei den Eingriffen ging es um die Beleglage. Da sind die Wikipediaregeln eigentlich sehr klar, und eine Grundsatzdiskussion muss deshalb nicht auf's Neue geführt werden. --Sunks (Diskussion) 16:20, 2. Jul. 2012 (CEST)Beantworten

Ich denke auch nicht, dass wir auf Mai zurücksteigen sollten. Nicht alles was seitdem geschreiben wurde ist schlecht, das was schlecht ist wird mit der Zeit wieder rauskommen.

Ich denke aber, dass wir das Treiben von Sunks genau beobachten sollten (ich werde das auf jeden Fall machen & bei gegebenen Anlässen reverten (wie bei seinen globalen Infoboxänderungen) & nehme da natürlich auch Sunksche Vandalismusmeldungen in Kauf). Ich denke zwar nicht das Sunks keine Ahnung hat (vielleicht haben mich seine Methoden aber verblendet), sein Umgang mit Entscheidungsprozessen in der Wikipedia ist allerdings fragwürdig. --Sebastian.Dietrich ✉ 17:05, 30. Jun. 2012 (CEST)Beantworten

(Am besten mit WikEd oder Schnark-Diff zu vergleichen)

• 34.644 bytes 2012-05-20 → 27.579 bytes 2012-06-28 – Kürzung um 20%

Die Löschungen gehen weitaus überwiegend auf Sunks zurück.

• Ich habe überhaupt nichts dagegen, wenn mal etwas knapper, klarer formuliert wird. Hier geht es um etwas anderes.
• Die inhaltlichen Löschungen von Sunks sind im Alleingang erfolgt; sie wurden zuvor nicht auf der Disku abgestimmt. Sofern die laufenden Löschungen anschließend überhaupt ansatzweise auf der Disku thematisiert wurden, hatte Sunks dann bereits weiter gelöscht, bevor ein Konsens gefunden war und als es noch deutlichen Widerspruch gab, und gleichzeitig schon die nächsten Abschnitte des allgemeinen Textes gelöscht (ich meine nicht die Kurz-Zusammenstellung in der Infobox).
• Inhaltliche Neugestaltungen durch Sunks kann ich nicht finden – bestenfalls Umformulierung der Überreste; ansonsten eigenmächtige Löschung, Löschung, Löschung, ...
• Derart grundlegende Überarbeitungen von Artikeln laufen anders ab; nicht ohne irgendeinen konkreten Anlass oder eine vorherige Absprache über Ziele und Vorgehen.
• Ich denke, dass jetzt eine Bestandsaufnahme erforderlich ist.

Schönes Wochenende --PerfektesChaos 20:11, 30. Jun. 2012 (CEST)Beantworten