Diskussion:Visual Basic Classic

Lemma

Dieser Artikel ist am 2. Oktober 2006 aus der Zusammenlegung der Lemmata Microsoft Visual Basic und Visual Basic .NET entstanden. Die früheren Artikelversionen sowie Diskussionen zu diesen Seiten finden sich dort (siehe „Diskussion:Microsoft Visual Basic“ und „Diskussion:Visual Basic .NET“). -- Stefan M. ausP.D. 17:58, 2. Okt 2006 (CEST)

Warum eigentlich? Visual Basic und Visual Basic .NET sind zwei unterschiedliche Dinge … C++ und C haben doch auch verschiedene Artikel. Die „Kritische Betrachtung“ würde ich rausnehmen, weil die Argumente größtenteils entweder nur auf VB 1-6 bezogen oder falsch sind. Unter dem Lemma Java (Programmiersprache) finde ich keinen einzigen Nachteil von Java, warum sollten im VB-Artikel welche stehen? Dass Diskussionen um Programmiersprachen eher mit Kriegen zu vergleichen sind, ist, denke ich, klar, das muss sich nicht auch noch auf Wikipedia ausbreiten. --Phst 21:35, 28. Okt. 2006 (CEST)

Diese Frage muss ich mir offengestanden auch stellen. Wenn man die Diskussion zum Thema betrachtet, so herrschte ja nicht gerade rege Beteiligung und darauf hin dann zwei so unterschiedliche Dinge zusammen zu fassen, IMHO sehr fragwürdig. Was spricht gegen zwei Artikel, einen mit Classic im Namen einem mit .NET und unter "Microsoft Visual Basic" hätte man die Auswahl zwischen beiden bekommen. Zudem sind so auch die vielen Fragen die auf der Diskussionsseite gestellt wurden und hätten in den Artikel eingearbeitet werden müssen wegeditiert. Schade. Florian Rittmeier 12:44, 2. Dez. 2006 (CET)

Hallo alle zusammen,
also ich finde das auch nicht gut, das diese beiden doch sehr unterschiedlichen Programmiersprachen hier einfach in einem riesigen Monsterartikel zusammengefaßt wurden. Wie ist der Verursacher eigentlich auf diese Idee gekommen? ..ich meine, (wie bereits auch schon angedeutet) würde ja z.B. bei „C“, „C++“ und „C#“ (und vielleicht sogar noch „D“ ;-) ) auch niemand auf die Idee kommen, all diese Artikel in einem zusammenzufassen.
Ich bitte also hier darum, diese Zusammenfassung wieder rückgängig zu machen.
Mit freundlichen Grüßen .. Conrad 18:09, 13. Mär. 2007 (CET)

Also ich denke, es wäre wirklich besser diesen Artikel hier nach Visual Basic Classic zu verschieben und aus Visual Basic eine Begriffsklärung zu machen, welche dann eben auf die einzelnen Sprachen (BASIC, VBA, VBC, VB.Net und was es da sonst noch gibt) verweist.
Mit freundlichen Grüßen .. Conrad 12:06, 6. Apr. 2007 (CEST)

Der Artikel ist immer noch ein Artikel, keine zwei getrennten. Wenn jemand Lust hat, bitte annehmen. --84.147.119.44 20:14, 12. Jul. 2009 (CEST)

Nette kleine Sprache

http://www.ddj.com/184403996 http://www.ddj.com/documents/s=1503/ddj0001vs/jan00.htm http://blogs.msdn.com/ericlippert/archive/2003/09/15/52996.aspx

Knuffig... ich erwarte entsprechend vernichtende Beschreibung innerhalb des Artikels.... MCSEs und "Microsoft Professionals" koennen es ja mit Altavista in Deutsch übersetzen damit sie es verstehen. Checkup 18:30, 23. Okt. 2006 (CEST)

Der Artikel von Verity Stob ist sachlich in vielen Punkten fehlerhaft: Comments on “Thirteen Ways to Loathe VB” by Verity Stob. --128.131.208.105 16:45, 8. Jan. 2008 (CET)

Der Artikel ist meines Wissens nach auch in der en.wp verlinkt. Lese ihn gerade noch mal genauer. (Anmerkung 1: Hoffentlich kommt keiner auch die Idee, das wirklich mit Babelfish zu übersetzen. Anmerkung 2: Die vier Konstanten der Apokalypse. Sehr lustig.) Der Artikel bezieht sich auf VB Classic, und VBC hat nicht nur ein paar Macken, was im Artikel m.E. nach auch ausreichend Erwähnung findet. Allerdings wurden viele dieser Probleme mit VB.NET (fast) komplett ausgemerzt.

Eine (wie du es nennst) „vernichtende Beschreibung innerhalb des Artikels“ halte ich aus den genannten Gründen für nicht angebracht, vor allem um den neutralen Standpunkt zu wahren. Gerade da VB so kontrovers diskutiert wird, habe ich mich im Abschnitt „Kritische Betrachtung“ bemüht, die Betrachtung so sachlich wie nur irgend möglich zu halten. Ich habe jetzt mal einen Einleitungssatz in den genannten Abschnitt eingefügt, mit Link auf die von dir benannte Seite. Ich möchte es nicht im neutral gehaltenen Artikel drin haben, die Leute sollten sich aber ein Bild machen können über die verschiedenen Gemütslagen bzgl. VB. -- Stefan M. aus D. 16:37, 23. Okt. 2006 (CEST)

Ich hab mich mal eingeloggt und auch das oben signiert. Hab einen msdn Artikel hinzugefügt der VB Programmierern Argumentübergabe erklärt. Das viele dieser Probleme bei VB.NET aus der Welt sind ist schlicht falsch. VB.NET hat dem ganzen noch einen Moment des Spaßes hinzugefügt. (-> Siehe Arrays beginnend mal mit Index 0 mal mit 1)

Ich hatte diese Links auch im alten Artikel auf der Dikussionsseite weil mich die Lobhudelei der MS-Pros genervt hat. Allein auf das Argument mit den Arrayindizes erhielt ich die Antwort "das das kein Argument für oder gegen ein Sprache bei einem großen Projekt ist".-> sehr süß.

Ich fasse den Artikel nicht an, will aber das hier Argumentativ klar gemacht wird das VB.NET eine Beginnersprache ist die man nicht in dem Sinne ernst nehmen kann wie eine "richtige" Sprache. Das soll dann auch hier mein letzter Beitrag zu diesem Thema sein, sonst muss ich noch mehr VB Horror ausgraben der hier als "Nichtigkeit" abgetan wird. :D Checkup 18:30, 23. Okt. 2006 (CEST)

Erstmal danke, dass du dich registriert hast.

Dass VB eine Beginnersprache ist, halte ich nun wieder für schlicht falsch. Ich habe mit Visual Basic .NET ein komplexes Paketmanagementsystem und einige andere systemkomponentennah operierenden Programme mit einer mehr als zufriedenstellenden Ausführungsgeschwindigkeit implementiert, und ich finde die Arbeit mit VB.NET angenehmer als mit C++ (auch wenn das wohl an der IDE liegt).

Auf die Gefahr hin, als MS Pro gebrandmarkt zu werden (was ich nun wirklich nicht bin), finde ich auch, dass Arrayindizes für sich genommen kein Argument sind. Ich weiß, dass VB vieles anders macht als andere Sprachen, macht aber dadurch vieles angenehmer, was ich persönlich als Vorteil sehe. Es kommt natürlich darauf an, ob man vorher schon in Sprachen der C-Syntaxfamilie geschrieben hat. Ich hab das mal in den Artikel reingebracht.

Was ich hier sehe, ist, dass sich die zwei Lager, die im Artikel meines Wissens nach auch erwähnt werden, gegenüberstehen: auf der einen Seite ich, der ambitionierte VB-Programmierer, auf der anderen Seite du, der ambitionierte VB-Hasser. Ich hoffe, dass dieser Konflikt auch aus dem Artikel klar wird. Gruß -- Stefan M. aus D. 09:44, 24. Okt. 2006 (CEST)

Die Indizes von Arrays in VB.NET laufen immer von 0 bis n − 1, wobei n die Anzahl der Arrayeinträge bezeichnet. --128.131.208.105 20:24, 7. Feb. 2007 (CET)

Kann man da einfach so hingehen und den Artikel aufteilen. Das glaub ich nämlich nicht. Was muss man zuvor tun. (Ich würd's nämlich machen wollen.) --Sannaj 18:01, 27. Nov. 2010 (CET)

Größte Informationssammlung über Programmierung der Welt??

Ich erachte diese Aussage als ziemlich gewagt! Ich möchte keinen Glaubenskrieg anzetteln, aber :

• Im MSDN bleiben nach wie vor sehr viele Fragen offen (meistens gerade die, die mich interesieren). Häufig finde ich NICHT die Informationen, die ich suche.
• MSDN ist unübersichtlich!
• Auch ist die Dokumentation des DirectX SDKs wesentlich besser als die VB .NET Doku.
• Desweiteren ist Dokumentation zu Java umfangreich geworden und auch downloadbar; dort finde ich fast immer was ich suche.
• Informationssammlung : ja; zu Programmierung (im allgemeinen): nein. Viele Lösungen von Microsoft werden in anderen Sprachen völlig anders gelöst! Es werden im MSDN nicht allgemeine Verfahren beschrieben, sondern nur Microsoft spezifische Programmierung!

Aus diesem Grund bin ich der Meinung, dass diese Aussage SO nicht haltbar ist. -- XhE 07:15, 21. Nov. 2006 (CET)

Ich habe die Formulierung ein bisschen entschärft: „Die MSDN Library [...] ist eine der größten Informationssammlungen für Programmierer.“ So besser?

Daneben bin ich der Meinung, dass die MSDN ganz und gar nicht unübersichtlich ist. Ich hab da meistens gefunden, was ich suchte, und oft noch mehr. Aber das ist wohl die persönliche Sicht der Dinge. Das mit dem "über Programmierung" meinte, dass es ein Werk ist, dass sich mit dem Programmieren befasst, was jedoch IMO nicht zwangsläufig bedeutet, dass Programmieren als Entität abgebildet wird. Wahrscheinlich ist das nicht oder nur kaum klar geworden. -- Stefan M. aus D. 09:39, 21. Nov. 2006 (CET)

Aussagen zur Geschwindigkeit

Es gibt im Artikel ja wieder fleißig Aussagen zur Geschwindigkeit im Vergleich zu anderen Programmiersprachen. Ich meine mich zu errinnern, dass zu diesem Thema bereits in der Diskussionsseite zum Artikel diskutiert wurde, als er sich noch primär auf VB Classic bezog. Man kann IMHO nicht einfach sagen diese Sprache ist schneller, diese ist langsamer, ohne die Rahmenbedingungen für diese Aussagen zu benennen. Es müsste zunächst untersucht werden, ob der geschriebene Vergleichscode schlicht ineffizient ist und dann sollte, sofern wirklich ein signifikanter Unterschied gefunden werden, angesprochen werden, warum es Geschwindigkeitsunterschiede gibt. Dies liegt wenn wahrscheinlich an bestimmten Sprachmerkmalen/Eigenheiten. Diese zu benennen wäre etwas, das ich von einem Artikel mit etwas wissenschaftlichen Anspruch erwarten würde. Florian Rittmeier 12:44, 2. Dez. 2006 (CET)

Nach Lektüre der alten Diskussionsseite habe ich die wesentlichen Aussagen entschärft und einiges aus Microsoft Visual Basic (Version vom 26. September um 13:11 oder so ähnlich) übernommen. -- Stefan M. aus D. 19:01, 2. Dez. 2006 (CET)

Die Geschwindigkeitvergleiche hinken in der Regel. VB hat den Ruf langsam zu sein, weil mit dieser Sprache eine deutlich größerer Anzahl von Anfängern und Hobbyisten programmieren. Diese haben im Allgemeinen keine wie auch immer geartetet IT-Ausbildung. Somit programmieren sie tendenziell eher nicht performanceorientiert.

Zudem: Die Aussage dass der mit VB5 eingefuehrte optionale(!) native Compiler die Programme schneller gemacht hat ist falsch. Die Erfarungen damit haben sogar gezeigt, dass MS mit der jahrenlangen Meinung, dass für VB ein P-Code-Compiler reicht, recht hatte. Der typische Anwendungsbereich ist GUI und Datenbank. Und da fällt es nicht auf, wenn eine Berechung statt einer halben eine vierte Millisekunde dauert, und dann die mehr als tausendfache Zeit auf die Daten der Datenbank oder gar auf eine Eingabe des Benuzters gewartet wird. Nur in sehr speziellen Fällen macht sich der Nativ-Compiler positiv bemerkbar. P-Code war/ist auch nicht so langsam wie immer behauptet. Zudem ist P-Code stabiler (so nebenbei: Auf der Wegfall Rückkompilerbarkeit hatte nichts mit dem Nativ-Compiler zu tun. Schon für VB4-Kompilate gab es kein Tool mehr, welches das bewerkstelligte. P-Code-Kompilate sind seitdem sogar deutlich besser geeignet, um sich vor Rückkompilierung zu schützen. Zudem laufen diese stabiler.) ---Ifm 01:40, 21. Okt. 2007 (CEST)

Wenn ist eine einzelne Operation durchführe, die anstatt 250ms in C unter VB dann 500ms läuft, dann spielt das in der Tat keine wirkliche Rolle. Wenn jedoch diese Operation viele tausend oder gar millionen mal durchgeführt wird, und sich die 500ms zu einer Stunde summieren, dann ist das gegenüber einer halben Stunde in C durchaus ein Performancekriterieum. Dennoch halte ich die Performancediskussionen für überzogen, da die meisten Anwendungen solche Performanceprobleme nicht kennen. --80.129.230.75 14:51, 22. Mär. 2009 (CET)

VB ist - zumindest in der Classic-Variante - wesentlich langsamer als andere compilierte Sprachen, definitiv. Ich programmiere schon recht lange und achte durchaus auch auf Performance - und krieg das in anderen Sprachen gebacken. In VB muss man halt so Dinge deaktivieren wie Überlaufkontrolle etc. Da wird viel Mist hineincompiliert, der dafür sorgt, dass ein VB-Programm nicht mit einer Windows-Fehlermeldung abschmiert sondern eigene Routinen ablaufen (On Error Goto xyz). Und die Grafikoperationen sind nicht gerade für ihre Geschwindigkeit bekannt. Dafür sind Fenster samt ihrer Control wesentlich schneller als dieses unsägliche, schnarchlahme Java/Swing-Zeugs. --84.147.119.44 20:14, 12. Jul. 2009 (CEST)

Kleine Unklarheit

"Wahr oder True wird als 1 interpretiert. In Visual Basic steht True aber für -1" ich kenne mich bei VB nicht aus. Heißt das, in Basic ist True = Minus Eins, statt Eins ? Wenn nein, sollte man eher schreiben: In Visual Basic steht '1' für 'True'.

in vb wird normalerweise NIE nach dem zahlenwert abgefragt, sondern nur nach "TRUE" oder "FALSE" somit ist das ziemlich sinnlos es ueberhaupt zu erwaehnen. Elvis untot 11:47, 6. Dez. 2006 (CET)

Die Ursache für das "-1" liegt in der in GWBASIC (ggf. auch noch frueheren MS-Dialekt) fehlenden Verfügbarkeit eine Unsinged- oder gar Bit/Boolean-Datentyps. Somit wurde auf "Integer" zurückgegriffen. Auf Bitebene arbeitet VB.classic (und Vorgänger) genauso wie (fast) alle anderen Sprachen auch. 0000000000000000 steht fuer False. True ist "Not False", also 1111111111111111. Da beim VB-Integer-Datentyp das letzte Bit das Vorzeichen repräsentiert, wird das -1 statt 1 (bzw. 65535). Die eigentlichen Probleme mit True/False liegen eher darin, dass "True" eine Konstante ist und per Definition der Wert 125 wahr ist. Ein "Dim a As Integer:a = 125: If a Then" wird nach der obenstehenden Logik verarbeitet, ergibt also True. Bei einem "If 125 = True Then" wird aber mit einer Konstanten mit dem Wert -1 verglichen, ergibt also False (siehe auch Newsgroup-Betrag mit der MID <01c7a821$3ba673e0$6401a8c0@xyz>) Was ich nicht weiss, ob das bei anderen Sprachen genauso ist. --Ifm 01:12, 21. Okt. 2007 (CEST)

Normalerweise ist alles != 0 doch wahr, wenn einem nicht der Compiler dank unterschiedlicher Typen einen Strich durch die Rechnung macht. "If 125 = true Then" schreibt kein Mensch, "If true = -1 Then" oder so auch nur Anfänger. --84.147.119.44 (20:14, 12. Jul 2009 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Ich habe schon häufig code wie "If x Then" gesehen, wobei x ein Long Integer o. ä. ist. Damit wird getestet ob ein Wert nicht 0 ist. Die genannte Variante ist halt schneller. --Ifm 23:21, 8. Dez. 2009 (CET)

Erklärung:

Bei der Auswertung mit IF wird - wie in anderen Sprachen auch - einfach auf nicht-Null (<> 0) geprüft. Deshalb funktioniert "a = 125 : If a Then ...", a ist also TRUE. Das ist aber etwas Anderes als ein numerischer Vergleich wie in "If a = vbTrue", was "If 125 = -1" entspräche!

Ed : --79.224.213.164 18:27, 9. Dez. 2012 (CET)

Nachteile aufgeteilt

Da sich fast alle Nachteile auf das schon lange veraltete Visual Basic Classic bezogen haben (und daher nur noch von historischem Interesse sind), habe ich den Abschnitt in "Nachteile von VB Classic" und "Nachteile aller VB Versionen" aufgeteilt. --Heinrich Moser 19:14, 8. Feb. 2007 (CET)

Gute Idee, ich habe noch einige weitere Nachteile in den allgemeinen Teil geschoben, da viele Sachen auch noch für VB.NET gelten. -- Stefan M. aus D. 16:57, 9. Feb. 2007 (CET)

Hmmm... danke, aber ich verstehe den Grund für's Verschieben nicht: Die Eingriffsmöglichkeiten ins System sind bei VB.net genauso ausgeprägt wie bei C#, Java und den meisten anderen nicht-systemnahen Sprachen. Auch ist mir nicht klar, warum du den zweiten Absatz verschoben hast: Das erste und dritte Beispiel gelten nicht mehr für VB.net und beim zweiten lässt sich streiten, ob das wirklich ein Nachteil ist. (Allgemeine Überlegung: Vielleicht wäre es überhaupt besser, es nicht in Vor-/Nachteile zu trennen sondern, ähnlich wie im Java-Artikel, die Unterschiede zu anderen Sprachen darzustellen? Die Wertung vieler Punkte ist ja doch nicht unumstritten.) --Heinrich Moser 18:30, 10. Feb. 2007 (CET)

---

• Visual Basic macht viele kleinere Dinge anders als andere Sprachen. Das erschwert das Übertragen von Programmen aus anderen Hochsprachen nach Visual Basic und umgekehrt. Auch erschwert es das Umlernen, wenn man bereits in einer anderen Hochsprache programmiert hat. Deshalb scheuen viele Programmierer den Umstieg auf Visual Basic und sehen Visual Basic im Vergleich z.B. mit Java nicht als Hochsprache an. Einige solcher Charakteristika sind nachfolgend genannt:
  • Üblicherweise hat der logische Wert Falsch bzw. False den Wert 0, Wahr oder True wird als 1 interpretiert. In Visual Basic bis Version 6 steht True aber für -1. Diese Konvention erlaubt es, den gleichen Not-Operator sowohl für die binäre als auch für die logische Not-Operation zu verwenden.
  • Die Vergleichsoperatoren sind in Visual Basic gleichzeitig die bitweisen Operatoren. Es hängt von der Art der Operanden ab, welche Operation durchgeführt wird.

---

Zum zweiten Punkt denke ich aus eigener Erfahrung schon, dass das auch noch bei VB.NET so ist. Ich wollte zum Beispiel eine Datei mit der Standardanwendung öffnen, also z.B. ein PDF gleich mit Adobe Reader. Die Alternativen für diese m.E.n. häufigen Problemstellung sind die DLL-Einbindung der ShellExecute und einiger anderer Win32-Funktionen oder das aufwändige Auslesen des "HKCR\.pdf" (oder ähnlich). Anderes Beispiel: Ich wollte ein Bild (System.Drawing.Bitmap-Objekt) aus 24-Bit-RGB in Schwarz-Weiß (also 8-Bit-Palette) konvertieren. Zuerst versuchte ich das Auslesen mit den Drawing.Bitmap-Methoden, was aber bei einem 1-Megapixel-Bild eine Minute dauerte. Also musste ich tatsächlich über irgendwelche Funktionen in irgendeiner Kompatibilitätsschicht die Bitmap-Daten in ein Byte-Array reinlesen und dort umrechnen. So reduzierte sich die Rechenzeit auf eine Sekunde. Solche Erfahrungen sind es, die mich zu dieser Einschätzung führten.

Den dritten Punkt habe ich jetzt hier rauskopiert. Der ist im Sperrfeuer der oben von mir angesprochenen Fronten als Kompromissvorschlag meinerseits entstanden, ist aber höchstwahrscheinlich für den Leser völlig uninteressant und kleinlich. Der dritte Punkt steht als Einzelpunkt bei VB Classic. Dabei ist mir auch ein Fehler aufgefallen, und zwar gilt False=-1, True=0 in VB.NET immer noch, wie ein Schnelltest unter VS05 ergab. Trotzdem denke ich mittlerweile, dass das da raus kann, freue mich aber auf deine Meinung. -- Stefan M. aus D. 11:02, 11. Feb. 2007 (CET)

Bzgl. True=-1: Du hast recht, ich habe es auch gerade getestet. Es ergab sich das folgende, interessante Ergebnis:

Console.WriteLine(CInt(True))            ' ergibt -1
Console.WriteLine(CType(True, Int32))    ' ergibt -1
Console.WriteLine(Convert.ToInt32(True)) ' ergibt 1

Da wäre evtl. ein eigener Absatz "VB im .net Framework" angebracht, wo auf diese Altlasten und Abwärtskompatibilitäts-"Features" eingegangen wird. Vor allem, da es ja auch so Spezialfälle wie '("" = Nothing) evaluiert auf True' gibt.

Bzgl. der System-Eingriffsmöglichkeiten: Ich verstehe, was du meinst, allerdings: Wäre das mit Sprachelementen von C#/Java leichter gegangen oder ist das einfach ein "Nachteil" von Hochsprachen an sich?

Bzgl. der Vergleichsoperatoren: Hast du da vielleicht zufällig gerade ein Beispiel bei der Hand? --Heinrich Moser 13:41, 11. Feb. 2007 (CET)

Wie gewünscht ein Beispiel:

If a = True And b = 6 Then
    x = 5 And 3 'ergibt x=1, wenn ich richtig gerechnet habe
End If

Zur Systemnähe: Ein interessanter Punkt. Es müsste wohl genauere Recherchen benötigen, um festzustellen, ob dieser Nachteil an der Programmiersprache oder am Framework liegt.

Der eigene Absatz zur Einbindung ins Framework wäre vielleicht wünschenswert. Man könnte, um den Bogen zu schlagen, auch die VBC-Funktionen beleuchten. Ich würde dies aber lieber nicht im Artikel, sondern auf einer Extraseite im Benutzernamensraum machen. -- Stefan M. aus D. 17:51, 11. Feb. 2007 (CET)

Danke für das Beispiel. Ich würde in dem Fall eher "logische Operatoren" statt "Vergleichsoperatoren" (darunter versteht man eher =, <>, <, >, ...) sagen. Aber ja, das kann (vor allem verbunden mit impliziter Konvertierung) ein Nachteil sein -- allerdings betrifft das wohl eher einige wenige Spezialfälle unsauberer Programmierung, daher weiß ich nicht, ob es wirklich eine Erwähnung wert ist. Operatorüberladung im Allgemeinen ist ja in Hochsprachen inzwischen auch nicht unüblich. Übrigens: In der Beta 1 von VB.NET war AND ein reiner logischer Operator und BitAnd musste für Binäroperationen verwendet werden. (http://archive.devx.com/dotnet/articles/fb_0628.asp)

Bzgl. der anderen Punkte habe ich mal versucht, diese wieder in den Artikel einzubauen und freue mich natürlich über Verbesserungen deinerseits. --Heinrich Moser 16:48, 12. Feb. 2007 (CET)

Sieht gut aus. Ich denke, das können wir erstmal so lassen. -- Stefan M. aus D. 13:56, 13. Feb. 2007 (CET)

Embedded Visual Basic?

moin, mir fehlt in dem artikel die erwähnung von embedded visual basic. wenn da jemand was zu schreiben könnte wäre es sicherlich nicht schlecht. cu AssetBurned 23:03, 20. Mär. 2007 (CET)

Stärkerer Fokus auf Visual Basic .NET

Ich bin mit dem jetzigen Aufbau des Artikels nicht ganz zufrieden: Die eigentlich nur noch historisch interessante Sprache Visual Basic Classic steht im Vordergrund, während Visual Basic .NET dann weiter unten abgehandelt wird. Das spiegelt eigentlich nicht die tatsächliche Bedeutung der Sprachen heutzutage wieder. Daher schlage ich die folgenden Änderungen vor:

1. Verschiebung der Visual Basic .NET-Box nach ganz oben.
2. Verschiebung der Visual Basic Classic-Box nach unten zu "Geschichte".
3. Anpassung der Lemmabeschreibung ganz oben.

Meinungen dazu? --Heinrich Moser 15:52, 1. Aug. 2007 (CEST)

Im Sinne von Wikipedia:Sei mutig habe ich diese Änderungen nun einmal durchgeführt. Ursprünglich hatte ich vor, die "Nachteile von Visual Basic Classic" in den Abschnitt "Geschichte" einzubauen, bin dann aber zu dem Schluss gekommen, dass diese ehrlich gesagt nicht wichtig genug sind (wie relevant sind heute noch Details über die Schwachstellen von PHP 3)? Die großen, historisch relevanten Kritikpunkte, die zur Entwicklung von VB.NET geführt haben, sind dort sowieso schon angeführt. --Heinrich Moser 17:11, 1. Aug. 2007 (CEST)

Die Relevanz ist schon gegeben. Spätestens wenn man zu einem Arbeitgeber wechselt, der schon lange im Geschäft ist und nicht alle paar Jahre sämtliche Teile seiner IT von Grund auf neu konzipieren lässt. Aus gutem Grund haben Manager keine Lust, erprobte Komponenten für viel Geld gegen neuere auszutauschen, auf denen der bisherige Stand nicht nahtlos weitergeht. Deswegen gibt es immer noch einen Markt für VBA-Programmierer, Leute mit VB6-Kenntnissen, Mainframe-Wissen, Assembler-Erfahrung... --Stammtisch 15:28, 14. Aug. 2007 (CEST)

Der Artikel sollte aufgeteilt werden in einen Artikel zu Visual Basic bis Version 6.0 und einen Artikel zu Visual Basic .NET. -- 213.235.200.3 16:15, 14. Aug. 2007 (CEST)

Freie Alternative

Moin, existieren freie oder gar open-source-Alternativen zu VB, oder die wenigstens der Syntax von VB ähnlich sind? --217.85.232.72 19:15, 18. Aug. 2007 (CEST)

Zu VB Classic: Gambas, zu VB.Net: SharpDevelop und Mono-Projekt. -- Stefan M. aus D. 12:11, 21. Aug. 2007 (CEST)

Eine weitere Alternative: Jabaco

Nachteile?

Hallo alle zusammen,
wieso wird eigentlich in diesem Abschnitt die Abwärtskompatibilität von VB.Net zu VBC als Nachteil dargestellt? Ich finde diese Abschnitte (also auch Vorteile) sollte man mal etwas neutraler formulieren oder ggf. ganz umstrukturieren, da die Vor- und Nachteile ja wohl sehr subjektiv von Mensch zu Mensch verschieden sind. Eine bessere Möglichkeit wäre z.B. die Abwärtskompatibilität in einem eigenen Abschnitt neutral, also ohne jede Wertung, darzustellen (siehe auch WP:NPOV).
MfG .. Conrad 11:35, 2. Sep. 2007 (CEST)

Es wird nicht die Abwärtskompatibilität an sich kritisiert, sondern die Tatsache, dass in VB.NET durch diese Kompatibilität kleine Inkonsistenzen entstehen (siehe die zwei Beispiele). Es stimmt, dass es Nachteile sind, allerdings halte ich persönlich das für technische Details, die den normalen Enzyklopedieleser nicht sonderlich interessieren.

Daher stimme ich deinem Vorschlag zu und halte es für eine gute Idee, die Vor-/Nachteile in den Text einzubauen anstatt sie in einer Liste anzuführen. --Heinrich Moser 22:42, 2. Sep. 2007 (CEST)

So, ich habe das jetzt einmal umgebaut und den Abschnitt "Kritische Betrachtung" in die Abschnitte "Einführung" (entspricht im großen und ganzen den alten "Vorteilen"), "Besonderheiten" (Eigenheiten wegen Abwärtskompatibilität, ehem. "Nachteile") und "Rechtliche Aspekte" (Proprietär, ehem. "Nachteile") aufgeteilt und den Neutralitätsbaustein entfernt. Dadurch ist eine leichte Überschneidung zwischen "Einführung" und dem Anfang von "Geschichte" hinzugekommen; wer sich berufen fühlt möge das bitte ein wenig verbessern. --Heinzi.at 16:09, 13. Nov. 2007 (CET)

Wo wir über die Vor- und Nachteile von VB.NET reden muss hier mal ganz klar unterschieden werden zwischen den Vor- bzw. Nachteilen der Programmiersprache VB.NET und denen des .NET-Frameworks (und von daher automatisch auch in gewisser Weise VB.NET). Das oben aufgeführte Performanceproblem mit der System.Drawing.Bitmap-Klasse ist e.g. ein Frameworknachteil, die Sache mit der unterschiedlichen Konvertierung von True und False als Zahl ein Problem der Kompatibilitätsschicht (man kann ja in VB.NET auch auf System.Convert zurückgreifen!) (nicht signierter Beitrag von Georg Hinkel (Diskussion | Beiträge) 00:14, 12. Nov. 2007)

VBA

Hallo, VBA wird nicht nur in MS-Produkten angeboten, so zum Beispiel bietet Mindjet Mindmanager auch ein VBA-Backend zur Erweiterung. (Der vorstehende Beitrag stammt von 91.96.102.230 12:50, 24. Oktober 2007 (CEST) und wurde nachträglich signiert)

So ist es. Daher findet sich dieser Hinweis in dem Artikel, der sich mit VBA befasst. --Ifm 23:20, 28. Okt. 2007 (CET)

Einige Details bzw. Korrekturen bezüglich Compiler, Interpreter und Laufzeitbibliothek bei VB

"Der Quellcode von Visual-Basic-1-Programmen wurde interpretiert, d. h. die Programme werden während der Ausführung, d. h. zur Laufzeit, in Maschinencode übersetzt. Zur Ausführung mussten deshalb sogenannte Laufzeitbibliotheken separat mitgeliefert werden; diese Bibliotheken übernahmen die erwähnte Übersetzung in Maschinencode."

Die Interpretation des Quelltextes erledigt normalerweise die Entwicklungsumgebung, in der man das Programm ohne Übersetzung ausführen (interpretieren) lassen kann. Der Interpreter kann dann zur Laufzeit Einfluss auf den Programmfluss nehmen, zum Beispiel Variablen auslesen und ihren Inhalt ändern, oder zusätzliche, zur Laufzeit eingegebene Befehle interpretieren, was das Debuggen von VB Code im Vergleich zu einer reinen Compilersprache sehr einfach macht. Die Laufzeitbibliotheken hingegen interpretieren keinen Quellcode, sondern einen Zwischencode, der abstrakter als Maschinencode, aber nicht so abstrakt wie der Quellcode ist.

"Visual-Basic-5-Programme wurden erstmals in nativen Code kompiliert. Damit war es – im Gegensatz zu den Vorgängerversionen – nicht mehr möglich, den Quelltext von Visual-Basic-Programmen aus der ausführbaren Datei zu extrahieren. Außerdem ergab sich ein erheblicher Performancegewinn. Durch diese Neuerungen eignete sich Visual Basic 5 erstmals auch zum Erstellen zeitkritischer Anwendungen. Trotzdem waren Visual-Basic-Programme immer noch langsamer als etwa C++-Programme."

Ich weiß nicht wie es bei älteren Versionen war, aber bei den VisualBasic Versionen 4 bis 6 wird der Quelltext entweder direkt interpretiert (aus den Quelltextdateien heraus) oder von einem Compiler in einen Zwischencode, so genannten P-Code, compiliert, welcher dann zur Laufzeit von einer virtuellen Maschine (mitgeliefert in der Laufzeitbibliothek MSVBVMxx.DLL, wobei MSVBVM vermutlich für "Microsoft Visual Basic Virtual Machine" steht) interpretiert wird. Das Verfahren ähnelt stark der Bytecode Implementierung von Java beziehungsweise der Common Intermediate Language des .NET Frameworks, welche allerdings stärkere Hardwareabstraktion bieten, als der P-Code Interpreter der VBVM. Die VBVM wurde deshalb kaum beziehungsweise überhaupt nicht auf verschiedene Plattformen portiert.

Auch die .NET Versionen compilieren in einen interpretierten Zwischencode (CLI). Unter VB Classic 5 und 6 gibt es weiterhin die Möglichkeit, nach Nativecode (also Maschinencode) zu compilieren. Allerdings bleibt auch hierbei ein (geringer?) Teil des Programm in Form eines interpretierten Zwischencodes bestehen, sodass auch so genannte "Native Code" VB Programme die Visual Basic Virtual Machine benötigen, um ausgeführt werden zu können.

Den Quellcode konnte man des weiteren noch nie aus der ausführbaren Datei (*.EXE) extrahieren, sondern höchstens den P-Code, der im Prinzip eine sehr leistungsfähige, interpretierte Assemblersprache ist, das heißt er besteht aus Mnemonics, wird jedoch interpretiert. Einige Decompiler können daraus vielleicht etwas "Quellcode-ähnliches" rekonstruieren, was allerdings nicht sehr brauchbar sein dürfte, da der Abstraktionsunterschied zwischen Quell- und P-Code doch enorm ist.

Wenn man mittels eines Debuggers oder Disassemblers den von VB erzeugten Code disassembliert, sieht man sehr wenige Assembler-Anweisungen, gefolgt von unzähligen, großen Datensegmenten. Der Code dient vermutlich einzig dazu, den P-Code Interpreter zu laden oder eine Fehlermeldung auszugeben, wenn dieser nicht vorhanden ist, während die Datensegmente den (interpretierten) P-Code enthalten. Eine Anwendung, die mit einer Compilersprache (wie C++) geschrieben ist, enthält dagegen vergleichsweise viel Code und wenig Daten.

Quellen:

Programmer's Heaven - Microsoft's P-Code Implementation A little about P-Code 217.94.202.128 21:57, 23. Nov. 2007 (CET)

Bezüglich des Decompilers: Es gab nur bis VB3 einen Decompiler. Ab VB4 hatte sich der Autor die Zähne ausgebissen. Der Satz Visual-Basic-5-Programme wurden erstmals in nativen Code kompiliert. Damit war es – im Gegensatz zu den Vorgängerversionen – nicht mehr möglich, den Quelltext von Visual-Basic-Programmen aus der ausführbaren Datei zu extrahieren. ist also falsch. Es werden aber immer noch Decompiler bis VB6 angeboten. Siehe auch [1] und [2]. --Ifm 23:45, 2. Jan. 2010 (CET)

Liste der vb-Befehle

Ich habe versucht, eine Seite mit allen vb-Befehlen zu machen. Sie wurde allerdings zum löschen markiert, und ich frage, ob nicht jemand anderes diese Seite machen könnte. Ich bin neu hier, daher habe ich einige Probleme. Ich programmiere auch in vb, auch wenn ich erst in der 5. Klasse bin! --Umweltschutz 16:40, 19. Feb. 2008 (CET)

Ein Jahr später antworte ich mir selbst: Nein, niemand wird die Seite machen, da sie nicht relevant ist.Umweltschutz Sprich ruhig! 11:17, 20. Jan. 2009 (CET)

Eine reine Auflistung ist wenig sinnvoll. Wenn du VB.NET meinst, wäre evtl. ein Artikel analog zu Sprachelemente von C# passender? --BSDev (Diskussion) 11:33, 20. Jan. 2009 (CET)

Indizierung beginnt bei 1?

Welche Programmiersprachen sollten das sein? Mir fällt keine ein. Und bei den wirklich wichtigen Sprachen (C++, C) beginnt auch die Indizierung bei 0? (nicht signierter Beitrag von 87.172.224.3 (Diskussion) 14:31, 6. Mär. 2008)

Sorry, ich verstehe die Frage leider nicht. Bei C++ und C begint die Indizierung bei 0, bei VB Classic wahlweise mit 0 oder 1 und bei VB.NET mit 0. Was wolltest du genau wissen? --Heinzi.at 15:01, 6. Mär. 2008 (CET)

Genauer gesagt, konnte man bei VB Classic die Indices beliebig bestimmen, z.B.: Dim arr(1981 To 2000)

Ed --79.224.199.163 15:23, 23. Apr. 2015 (CEST)

Bilder

Hallo, ich habe mir erlaubt, zwei Bilder aus der Englischen Wikipedia in die deutsche einzufügen. Hier die Orginalquellen:

http://en.wikipedia.org/wiki/Image:Microsoft_Visual_Basic_for_MS-DOS_%28Professional_Edition_Version1.00%29.png

http://en.wikipedia.org/wiki/Image:VBDOS-icon.PNG

Ich hoffe sie kommen gut an. Wenn dies nicht der Fall sein sollte, bitte ich sie wieder zu löschen. --Ferdinand f. 09:11, 22. Mai 2008 (CEST)

Edit: Habe jetzt noch eines erstellt, welches das Hilfesystem Demonstriert. --Ferdinand f. 10:20, 22. Mai 2008 (CEST)

Mal wieder das Übliche...:

Schreiber, die Kenner und als solche so betriebsblind sind, dass ihnen der Blickwinkel der Allgemeinheit komplett aus dem Horizont geraten sind, bzw. die nicht mal das Naheliegendste von allem sehen: Das Zeug heißt VISUAL Basic -wieso eigentlich?? "Basic" gab es schon; es ist also davon auszugehen, dass der Zusatz "Visual" also einen Hinweis darauf geben soll, was bei diesem Basic das Besondere ist -so besonders, und evtl. sogar so charakteristisch, dass man es danach benennt!

Meine eigene Neugier auf das Zeug entzündete sich (und da dürfte ich weiß Gott nicht der einzige sein) gerade an diesem Namensteil: Gibt es hiermit jetzt endlich eine Hochsprache, die sich CAD-artiger Möglichkeiten der Symbolbenutzung bedient (etwa Einbau der Sprachelemente durch Anklicken oder drag&drop), so dass man nicht nur Schreibfehler, sondern auch anderer Syntaxfehler enthoben wird , wie vergessene syntaktische Sprachelemente, log. Verzweigungen, Typ- oder Indexgrenzprüfungen, so dass man z. B. das Gerüst einer Schleife mit allem "Zubehör" auf "Knopfdruck" eingesetzt kriegt, was einem viel Formalkram abnimmt und gewisse Fehler vermeiden hilft und auch die optische Lesbarkeit des Quelltextes enorm erleichtert und beschleunigt. "Visual" halt! (Von sowas träum ich schon seit 20 Jahren.) Aber wo kämen wir hin, wenn wir erst mal das Naheliegende besprechen würden...? Statt dessen volle Kanne in Massen ätherische Details dreschen, die dem Nicht-Experten an den Kopf geschmissen werden und vielfach unverständlich bleiben oder aber einem der Lese- und Verstehensfluss durch Ballungen von Verweisen verstümmelt wird. Heißa, was können wir uns da in Vorsprungswissen hoher Abstraktionsstufen ergehen! Wenn der Pöbel das nicht rafft, soll er sich doch ein einführendes Buch kaufen! - Yog-S, --213.102.97.215 06:29, 9. Jan. 2009 (CET)

Hätte ich kein Problem mit, wenn diese Microsoft-Wiki-Artikel nicht allesamt zur kollektiven Verblödung beitragen würden. Köstlich auch der hochwichtige Abschnitt "Besonderheiten", eine Ansammlung unwichtiger Kuriositäten. Aber die Nichtthematisierung von "Visual" toppt auch diesen. Natürlich. Fahnder99 10:14, 26. Aug. 2010 (CEST)

Seltsamer Rave. Es gab & gibt etliche "Visual"-Produkte, nicht nur von Microsoft. Das Thema der (nicht-) visuellen Programmierung müsste man also immer allgemein & an anderer Stelle behandeln. Es ist außerdem - vielleicht aber tatsächlich nur für "Kenner"? - klar, dass sich "Visual" hier auf die IDE sowie die Gestaltung der Programmoberflächen (GUIs) bezieht. Das war im historischen Kontext, als Programmierung weitgehend mittels Editor, Kommandozeilen-Tools und Make-Files erfolgte, durchaus etwas Besonderes. Ed --79.224.213.164 19:18, 9. Dez. 2012 (CET)

Lücke

Hi Leutz, Ich habe gerade entdeckt, dass bei VBDOS, VBWIN1.0 eine riesige Lücke ist. Habe sie aber leider nicht entfernen können. Kann das mal bitte jemand tun?? Danke, --Ferdinand f. 13:54, 25. Apr. 2009 (CEST)

Ok hat sich erledigt --Ferdinand f. 13:57, 25. Apr. 2009 (CEST)

Syntaxbeispiele /-hervorhebung

Die Syntaxhervorhebung der Beispiele im .NET-Teil stimmt nicht mit der des Visual Studio überein. Nachdem die Farbgebung bei VB-Classic der originalen entspricht, sollte das bei .NET genauso sein. --Sigemi 19:47, 26. Jul. 2009 (CEST)

"Visual Basic" ist "geistiges Eigentum von Microsoft"?

Der Satz ist falsch oder zumindest missverständlich. Die Sprache ist mit Sicherheit kein geistiges Eigentum. Die konkrete Implementierung des Compilers/Interpreters in Form von "Microsoft Visual Basic" ist geistiges Eigentum. Mich als Entwickler würde allerdings rein rechtlich gesehen nichts daran hindern, einen eigenen Interpreter zu entwerfen, der zu dem von Microsoft kompatibel ist, solange ich dafür keinen Code aus der proprietären Implementierung übernehme. 217.94.202.213 19:33, 13. Aug. 2009 (CEST)

deutsches VBDOS

Im Artikel steht VBDOS war nicht so erfolgreich wie die Version für Windows, sodass es nie eine deutsche Version. Das ist falsch. Ich habe selber mit der deutschen Version gearbeitet. BASIC PDS gab es nur in englisch. Ich nehme den Satz raus. --Ifm 23:02, 2. Jan. 2010 (CET)

Me oder MyBase?

In dem Abschnitt "Syntax von Visual Basic .NET" ist folgende Codezeile zu Finden:

    Private Sub Form1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load

Meines Erachtens müsste es aber

    Private Sub Form1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles MyBase.Load

heißen. Nun bin ich kein Fachmann und weiß nicht, was stimmt. Es wäre gut, wenn sich jemand, der sich mit VB auskennt, den Fall mal anschaut. --Mark553 21:29, 8. Jul. 2010 (CEST)

Beides funktioniert. Wenn man den Code automatisch genrieren lässt, wird die zweite Variante genriert. MyBase bezieht sich auf die Klasse, von der das spezielle Form erbt; Me auf die aktuelle Klasse. --Fehlerkorrektur 10:37, 28. Jul. 2011 (CEST)

Patentierung des IsNot-Operators angezweifelt

Neben der Tatsache, daß dieser Operator durch eine einfache Negation mit dem Is-Operator umgangen oder dieser damit ersetzt werden kann – so ergibt meiner Interpretation nach (sogar nach Microsoft selbst)^[3]

If Not o1 Is o2 Then

und

If o1 IsNot o2 Then

das Gleiche, und mit

If o1 Is Not o2 Then

müßte wohl auch das gleiche Ergebnis herauskommen – scheint mir diese (Trivial-)Patentierung des IsNot-Operators nicht besonders relevant und zudem auch veraltet zu sein (siehe dazu auch Stand der Technik). Desweiteren bezweifle ich, daß darauf überhaupt tatsächlich ein Patent vergeben wurde – wahrscheinlicher erscheint mir eher ein Übersetzungsfehler oder ähnliches vorzuliegen. Bitte also mal die betreffende Quellenangabe dahingehend überprüfen und die Teile dann ggf. (wegen mangelnder Relevanz oder Schleichwerbung) aus dem Artikel entfernen.
--Konrad – 17:45, 21. Dez. 2010 (CET)

Weblinks Aktualität und Qualität

Einige Links zeigen in Nichts und die Andren sind fast nutzlos: z.B. die "Podcasts" vermitteln keine Infos, es redet jemand über Sachen, die nur am Rande etwas mit dem Thema zu tun haben. Konnte man nicht aus den Podcasts Unsinn ausschneiden und schwuchtelige Stimme durch männliche oder weibliche ersetzen?

92.50.77.9 10:25, 24. Jul. 2011 (CEST) Anfänger

Besonderheiten

Zitat: "Visual Basic .NET erlaubt es, anders als zum Beispiel C#, globale Variablen ohne Klassenzugehörigkeit zu definieren."
Ist nicht richtig.
Die wirkliche Besonderheit ist, dass VB.Net keine statischen Klassen kennt, und stattdessen das "Module" - Konstrukt benutzt, welches im wesentlichen eine statische Klasse ist.
Der angesprochene OOP-Grundsatz "keine Deklaration ohne Klasse" kann also auch in VB.Net nicht verletzt werden. -- ErfinderDesRades 13:29, 18. Sep. 2011 (CEST)

Was denn jetzt? Objektorientiert oder nicht?

Im ersten Absatz heißt es

Visual Basic Classic [...] ist eine proprietäre objektorientierte Programmiersprache.

Weiter unten hingegen

Dadurch eignet es sich für Rapid Application Development. Visual Basic Classic, das noch nicht die objektorientierten Fähigkeiten von VB.NET hatte, wurde oft eingesetzt, [...]

Visual Basic 6 war definitiv keine objektorientierte Programmiersprache, da es weder Vererbung, noch Polymorphie kennt. 217.7.236.13 10:57, 5. Mai 2014 (CEST)

VB 5/6 sind schon objektorientiert (Daten und Programmteile können in Klassen zusammengefasst werden), aber besitzen halt nicht alle objektorientierten Fähigkeiten von Java/VB.Net. Daher können die beiden genannten Absätze so stehen bleiben. Zur Klarstellung werde ich "noch nicht die OO-Fähigkeiten" durch "noch nicht alle OO-Fähigkeiten..." ersetzen. -- Jost aus Soest (Diskussion) 16:59, 5. Mai 2014 (CEST)

Nein, VB Classic ist keine OOP-Sprache. OOP besteht aus weit mehr als Klassen und Objekten und es ist leider so, das viele Programmierer auch heute noch eine objektorientierte Sprache verwenden, aber nicht objektorientiert programmieren. So kennt VB Classic keine Überladen von Methoden, keine Vererbung, keine Delegaten und kein Überschreiben von Methoden. Damit bleibt von der Polymorphie der Objektorientierung exakt nichts übrig und sie ist eine Kernaussage der objektorientierten Programmierung, die darauf abziehlt, bestehende durch Vererbung wiederzuverwenden und zu erweitern. Auch Elemente wie Generika, Reflektion und Operatorenüberladung kennt diese Sprache nicht. Die Bildung von Klasse in nur eine von vielen Facetten der OOP-Programmierung. VBC war ein Basic mit Objekten und für manche Einsatzzwecke keine schlechte Sprache - sie war halt nicht objektorientiert. "War" deshalb, weil die Bedeutung heute gegen Null geht. Eine Aussage "noch nicht alle OO-Fähigkeiten..." ist zu ersetzen mit "es fehlen essentielle Eigenschaften einer objektorientierten Sprache". Die Bezeichnung "Visual Basis Classic ist ein Basic mit Objekten" trifft es noch immer am besten.79.212.160.108 19:17, 20. Jul. 2014 (CEST)

"Objektorientierung" heißt nunmal per Definition einfach nur "Daten und zugehörige Programmteile zu einer Einheit zusammenzufassen" (s. a. Objektorientierung), was in VB5 und co. 100%ig funktioniert. Dass viele OO-Sprachen mehr Fähigkeiten besitzen ändert nichts an diesem bereits hinreichendem Kriterium einer OOP! --Jost aus Soest (Diskussion) 23:50, 20. Jul. 2014 (CEST)

Vergangenheit

VB Classic ist ja schon Vergangenheit (nicht VB.Net) - sollte daher der Artikel nicht in der Vergangenheitsform geschrieben werden? --Sebastian.Dietrich ✉ 20:09, 21. Mai 2015 (CEST)

Nicht wirklich. Zur Verwendung von Zeitformen vgl. z.B. den Artikel über die chinesische Siegelschrift. Selbst wenn wirklich niemand mehr VB Classic nutzen würde, ist für die Beschreibung der Sprache selber die Gegenwartsform zu benutzen, da hier ein Konzept und nicht eine Handlung beschrieben wird. Dagegen wurde für die Beschreibung der Chronologie der Sprachentwicklung korrekterweise die Vergangenheitsform verwendet. lg --Sannaj (Diskussion) 05:07, 16. Mär. 2016 (CET)