Diskussion:Microsoft Visual Basic

Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 4. Mai 2005 um 20:53 Uhr durch Wizzar (Diskussion | Beiträge) (Schnelligkeit). Sie kann sich erheblich von der aktuellen Version unterscheiden.

ich habe gerade einen revert durchgefuehrt, da ein anonymer nutzer bis auf den m$ link alle weblinks geloescht hat.

ich sehe ja ein, dass es hier ziemlich viele geworden sind, aber einfach alle loeschen halte ich fuer falsch. also diskussion: welche weblinks sollen weg, welche sollen bleiben? Elvis untot 15:37, 18. Nov 2004 (CET)

Ich würde mal sagen, dass es sinnvoll ist, an dieser Stelle auch auf die großen deutschsprachigen Visual Basic Communitys zu verweisen. Für Interessierte wäre dies sicherlich eine gute Möglichkeit an weitere Informationen zu gelangen. Alternativ könnte man auch das [Community Verzeichnis – MSDN / Entwickler] aus dem [Microsoft Community Guide] verlinken, wobei in diesem auch andere Communitys verlinkt sind. -- Florian Rittmeier 01:31, 4. Apr 2005 (CEST)

Übersetzungsdetails

Hat jemand einen Beleg dafür, dass VB intern in C++ übersetzt wird? Kommt mir merkwürdig vor - ich denke VB wird intern in P-Code bzw. Maschinencode übersetzt! --RKraasch 20:58, 16. Jun 2003 (CEST)

Ja, es wird ein Bytecode generiert. Ich habe das mal angepasst, hoffe, es hat keiner etwas dagegen. -- Jens Benecke (20.11.2003)


Ganz offenbar scheint ja Diskussionsbedarf in Bezug auf einige Punkte zu bestehen - vielleicht sollten wir das ganze erstmal ausdiskutieren, bevor wir uns ständig gegenseitig den Text ändern.
Kurz meine Sicht der Dinge:

  • VB eignet sich auch für große Projekte (gerade noch selbst erlebt) allerdings nervt irgendwann der Mangel an vernünftiger Fehlerbehandlung und richtigem OOP gewaltig. Der Zeitaufwand ist dann immer noch geringer als bei einem C++ Projekt, ist aber teuer erkauft. --cvk
    • aus gründen der neutralität sollte das im artikel etwas anderes formuliert werden (wir sollten hier einfach keine konkreten empfehlungen abgeben, fakten dürften in diesem Fall aber ausreichen, wenn du konkrete Argumente hast)
  • Der Vergleich mit PHP hinkt gewaltig. PHP ist keine Programmiersprache, sondern eine Scriptsprache die einzig und allein zum Erzeugen von Webseiten benutzt wird. Ein Vergleich zwischen ASP/VBScript und PHP würde funktionieren - alles andere ist grober Unfug. --cvk
    • Sehe ich anders, bzw. trenne ich erstmal nicht zwischen Programmiersprachen und Skriptsprachen - wo soll da der genaue, klar definierte Unterschied sein?
      • Streng genommen ist der Unterschied einfach der, dass eine 'Scriptsprache' interpretiert und eine 'Programmiersprache' kompiliert wird.
        • Nö, das ist für mich der Unterschied zwischen einer Interpreter- und einer Compilersprache.
          • ...und eine Scriptsprache üblicherweise keine explizite Typdeklaration verlangt und keine Strukturierungsmittel bietet. Außerdem wäre da noch die Sache mit dem Einsatzgebiet: --cvk
      • Entscheidender ist aber der Einsatzzweck: Niemand käme auf die Idee, mit PHP die selbe Applikation wie mit Python zu schreiben, obschon beide nach dieser Definition 'Scriptsprachen' sind. Natürlich bin ich mit meiner Behauptung, PHP sei keine Programmiersprache ein wenig polemisch gewesen, aber PHP als Alternative zu VB... das geht einfach nicht. --cvk
        • es gibt PHP, Perl, Python, Java, JSP, awk, C, C++, Cold Fusion, CLisp, Prolog, Rebol, Ruby, Scheme, Smalltalk, Tcl und *ähemm* VisualBasic- und ASP Wikis. Was war noch mal dein Punkt? ;-) aber ich würde hier mal ein EOD vorschlagen... --elian
          • Ich gebs auf. Du hast recht und ich meine Ruhe :) --cvk
  • Perl ist ebenfalls keine Programmiersprache, sondern eine Scriptsprache. Perl ist wenn überhaupt mit VBScript vergleichbar aber ich neige dazu, Perl nicht im gleichen Satz wie diese Ausgeburt der Hölle zu nennen. --cvk
    • :-)
  • KDevelop ist keine wirklich Alternativen zu VB. KDevelop ist eine Entwicklungsumgebung für Betriebssysteme unter denen VB vermutlich niemals laufen wird. Und irgendwie wiederstrebt mir der Gedanke, Qt als Alternative zu VB anzugeben. --cvk
    • ACK. Das ist mir auch schon aufgestossen. Das sollte komplett raus. --elian

grade den Artikel in der aktuellen Form gelesen und würde sagen, er paßt so recht gut (auch die aufteilung Java/C vs. PHP/Perl) --elian


Und hier der Backlink zum Artikel: Visual Basic

Dazu gibts auch auf jeder Diskussionsseite den - etwas schwer zu findenden - Link "Artikel".

Stimmt, jetzt seh ichs auch - also weg damit :) --cvk
diese durchstreiche-technik hat was...das werd ich mir in der englischen WP auch angewöhnen --elian

Link auf ein Projekt eine VB-ähnliche Umgebung zu schaffen. Es gibt mehrere solche Projekte. Unkommentiert kann man das nicht im Link-Bereich einfügen. Das Projekt ist erst in Version 0.43. Der Anspruch es sein ein VB für Linux ist zu vollmunding zur Zeit.

Eine gute aktuelle Übersicht über die Anstrenungen im Linux-Bereich mit Basic zu arbeiten findet sich hier.

Statisches Linken

"Darüber hinaus wurde das statische Linken von Programmbibliotheken nicht unterstützt." - Wird nicht automatisch unterstützt, kann aber mit entsprechenden Parametern bei manuellem Aufruf des Linkers ohne Probleme realisiert werden - soll es drinbleiben, weil es nicht ohne aufwand möglich ist, oder gelöscht werden, weil eigentlich falschinformation? --APPER 13:33, 26. Apr 2004 (CEST)

drinnlassen, mit entsprechender aenderung. Elvis untot 17:42, 6. Jul 2004 (CEST)

Meines Wissens und meiner langjährigen Erfahrung nach ist dies nicht möglich. Dies würde AFAIR voraussetzen, dass Microsoft Bibliotheken zum statischen Linken beigelegt hat, und von diesen sind hab ich bisher keine gesehen. Auch Produkte wie Bitarts Fusion sind im Endeffekt nur EXE-Binder. -- Florian Rittmeier 01:31, 4. Apr 2005 (CEST)

Schnelligkeit

Zitat: "Obschon die Programme, die man mit Visual Basic erstellt, noch immer langsamer ablaufen als in der Programmiersprache C geschriebene Programme" IMHO ist das nur ein Gerücht; in VB5 und VB6 mit Native Code laufen meiner Erfahrung nach VB-Programme genauso schnell wie C-Programme, vorausgesetzt, die Compileroptimierungen werden genutzt. Dadurch kann die Laufzeit-Fehlerbehandlung ausgeschaltet werden (die sind nämlich der einzige Grund, warum VB-Programme ohne Optimierung geringfügig langsamer als C-Programme sind). Autoren wie Bruce McKinney ("Hardcore Visual Basic") sind in Tests zu gleichen Ergebnissen gelangt. --Phrood 01:05, 6. Jul 2004 (CEST)

dazuschreiben, dass es haeufig behauptet wird, dass aber kein objektiver test bekannt ist, der diese behauptung unterstuetzt. Elvis untot 17:42, 6. Jul 2004 (CEST)
Sehe ich nicht so, vor allem bei grafischen Operationen ist Visual Basic wirklich wesentlich langsamer als z.B. C++, Unterschiede von 100 (VB) zu 5 (C++) ms sind keine Seltenheit. -- KL47 22:33, 2. Sep 2004 (CEST)
welche graphischen operationen? werden auch die gleichen objekte zur anzeige genommen, oder speziell programmierte und angepasste? wenn du mir sagen kannst, dass z.B. ne vektorberechnung X% langsamer ist, kann ich das aktzeptieren, aber so, ist es leider noch eine null-aussage (ich glaube es ja, dass vb an manchen stellen wirklich langsamer ist, aber diese stellen muessen wir dann schon genau bezeichnen. graphische operationen ist ein zu offenes feld imho)Elvis untot 08:24, 3. Sep 2004 (CEST)
Es wundert mich immer wieder, wie hartnäckig sich Vorurteile halten. VB ist nicht langsamer. Warum sollte es auch, wo doch bei VB5/6 Maschinencode generiert wird? Wenn du derart langsame Ergebnisse erzielt hast, liegt das daran, daß du nicht alle Kompilieroptionen aktiviert hast oder die Grafiken auf die falsche Weise ausgegeben hast (kein Blitting). Ich habe bereits in VB Code geschrieben, der echtes Alpha-Blending von größeren Bildern (512x512) in Echtzeit durchführen konnte - ohne Zuhilfenahme von externen Funktionen. --Phrood 00:44, 7. Nov 2004 (CET)

Visual Basic 6 ist bei Berechnungen langsamer; siehe z.B. Michael Koflers "Visual Basic 6" in dem er das Thema z.B. in Bezug auf die Berechnung der Mandelbrotmenge behandelt. Und nur dass Maschinencode produziert wird sagt noch nichts ueber die Geschwindigkeit aus; z.B. generieren ja auch Compiler verschiedener Hersteller und auch verschiedene Versionen unterschiedlich schnelle Programme. Sprachen wie C sind einfacher zu optimieren. Ausserdem nutzt Visual Basic ja ausfuehrlich in C geschriebenen Code; bloss dass dieser noch einmal extra fuer Visual Basic in Dlls gekapselt ist. Das bedeutet dass nur ein Teil des Maschinencodes ueberhaupt vom VB-Compiler produziert wird und fuehrt ausserdem zu Overhead der bei Eigen-Implementation in C (hoffentlich) nicht entsteht. Alpha-Blending eines einzelnen Bildes ist ja nett, aber ich habe noch nicht von z.B. aktuellen Spielen wie Ego-Shootern gehoert die in VB geschrieben waeren; was ja wohl auch nicht nur auf Sprachpraeferenzen zurueckzufuehren sein kann. Die momentane Artikelfassung, inhaltlich grob "fuer vb5 und vb6 sind die geschwindigkeitsunterschiede unwesentlich", ist deswegen meiner Meinung nach falsch und wurde von mir geaendert.

Windows Services

Ich denke das die Behauptung "Auch Windows-Services ließen sich vor VB.NET nur umständlich implementieren." so nicht haltbar ist. Microsoft selbst bietet dazu für VB5+6 ein Steuerelement an mit dem das absolut kein Problem darstellt. Siehe: http://support.microsoft.com/default.aspx?scid=kb;en-us;170883 Man muss dazu die Sprache beherrschen aber das ist in anderen Sprachen auch nicht anders. (Ich würde es gerne editieren aber ich kenne mich mit dem Wiki System nicht aus und lasse es deshalb um nichts kaputt zu machen.)

Es ist zwar dank des genannten Steuerelementes durchaus einfach einen Dienst mit VB zu implementieren, Microsoft weißt jedoch im Artikel INFO: Running Visual Basic Applications as Windows NT Services explizit darauf hin, dass man es bleiben lassen sollte. Daher wäre es vielleicht sinnvoll den Satz dahingehend zu ändern, dass es für Visual Basic Classic machbar, aber nicht empfehlenswert ist. -- Florian Rittmeier 01:31, 4. Apr 2005 (CEST)