Re: Migration auf .NET - Winform or WPF or Silverlight or ?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Hallo Peter!

"Peter Fleischer" <peter.fleischer_nospam_@xxxxxx> schrieb:
Classic VB war im Laufe seines Lebens in vielerlei Hinsicht sogar recht fortschrittlich, ...

ich stelle überhaupt nicht in Frage, dass VB1-6 in vielerlei Hinsicht fortschrittlich war. Auch ist es aus heutiger Sicht recht einfach, darüber zu urteilen :-) Wenn ich aber nur das Thema Typsicherheit herausnehme, so wurde das Thema recht stiefmütterlich behandelt. Da gab es damals bereits konkrete Erkenntnisse und Umsetzungen, wie beispielsweise in dem von mir bereits genannten Modula2. Mir ist z.B. bis heute unklar, warum man auch in den Vorlagen zum Visual Studio.NET "Option Strict Off" als Voreinstellung ausliefert.

Da stimme ich Dir schon zu. Allerdings ist die Typsicherheit von z.B. C noch wesentlich geringer ausgeprägt als jene von VB und Microsoft vertreibt immer noch einen C-Compiler. In VB konnte man (mit Bordmitteln) zwar recht leicht fehlerhaften, aber dennoch kompilierbaren Code schreiben, Probleme wie Speicherzugriffsverletzungen etc., wie man sie aus C kennt, waren damit aber nicht möglich. Modula-2, mit dem ich auch arbeitete, scheiterte wohl an der mangelhaften Unterstützung durch Entwicklungswerkzeuge und (praxisrelevante) RAD-Bibliotheken.

Das Hauptproblem bei einer Migration sind nach meiner Erfahrung die vielen Tricks, die in VB6 notwendig waren, um bestimmte Funktionalitäten zu realisieren. Hinzu kommt der oft unsaubere Programierstil, den der VB6-Compiler toleriert hat, und eine unzureichende Strukturierung der Programme.

Das Hauptproblem sind m.E. vorwiegend die "anderen", nicht mehr kompatiblen Bibliotheken und die geänderte Syntax.

Hast du mal VB6-Programme konvertiert? Meine Erfahrung ist eine andere. Wenn man vor der Konvertierung den Visual Basic 6.0 Code Advisor laufen lässt, dann merkt man erst einmal, wie "unsauber" programmiert wurde.

Ich hatte es nur testweise mehrmals versucht. Mein Resümee war, daß ein Neuentwurf sinnvoller ist, insbesondere dann, wenn ein grober Bruch (z.B. Benutzerschnittstelle mittels WPF, LINQ im Hintergrund etc.) mit alten Technologien erfolgen soll. Wenn ich mir in den C#- und VB.NET-Newsgroups den geposteten Code ansehe, kann ich nur feststellen, daß auch mit diesen beiden Sprachen "unsauber" programmiert werden kann.

Schließlich waren diese "unzureichend strukturierten Programme" so gut strukturiert, daß sie der VB6-Compiler problemlos verarbeiten konnte.

Solche Aussage von dir? Dass den Compiler keine Struktur interessiert, wenn die Syntax richtig angewandt wurde, ist die Grundlage dafür, dass der Compiler überhaupt funktioniert.

VB6 bot andere Strukturierungswege als VB.NET. Ich würde aber deshalb den VB6-Weg nicht als unsauber bezeichnen. Und ich würde VB6 auch nicht deshalb als unsauber bezeichnen, weil es viele ahnungslose Entwickler gab, die massenweise Code in ein Modul packten oder sich Tricks (Assembler-Einbettung etc.) bedienten.

Und der arbeitete nicht beliebig, sondern nach bestimmten, zumindest teilweise offengelegten Regeln. Idealerweise könnte man im VB7 bestehenden Code 1:1 weiterverwenden und zugleich von .NET Framework wie in VB.NET Gebrauch machen. Zwischen den beiden Welten würde eine IJW-ähnliche Technik stehen.

Ich finde die derzeitig angebotenen Mittel für eine Migration von VB6 nach VB.NET nicht schlecht. Sie helfen ungemein, erlauben aber nicht automatisch alle Sünden der vergangenheit zu korrigieren.

Die Sünden waren damals keine Sünden!

Mit Sünde meine ich vor allem das Gewöhnen an Arbeitsweisen, für die der Compiler Abläufe generiert, die nicht in jedem Fall die erwarteten Ergebnisse liefern, wie beispielsweise die implizite Typkonvertierungen, die Nutzung von Standardeigenschaften.

Das ist aber doch eher ein menschliches Problem. Ich sehe hier bei VB.NET keine substantiellen Vorteile, selbst dann, wenn Typüberprüfung aktiviert ist (vgl. 'CDate').

Sie waren, genau so, wie die jetzige Verwendung von VB.NET, die Kunst der Technik, der Stand der Entwicklung. Ich warte nur darauf, bis dereinst Code, der z.B. von WPF oder LINQ Gebrauch macht, a-posteriori als Sünde abgestempelt wird, weil es dafür keinen direkten Migrationsweg gibt.

Dagegen sind wir nicht gefeit. Mit einem zukünftigen Erkenntnisstand kann es möglich werden, das die Bereitstellung einiger Techniken ein Irr- oder Umweg war. Ich bin mir nicht sicher, ob var (in C#), anonyme Typen, die Bindungsmöglichkeiten in WPF in dieser Form wirklich länger Bestand haben werden, obwohl sie natürlich angenehm (bequem) sind.

Im Nachhinein machen wir es uns oft zu einfach, Dinge, die nicht mehr unterstützt werden, allein deshalb als unsauber zu bezeichnen. Programmieren ist immer Ausnützen dessen, was durch einen Vertrag (Programmiersprachenspezifikation) ermöglicht wird.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

.

Relevant Pages

  • Re: [VB?] & Java ...
    ... Der Autor Manuel Siekmann bzw. dessen Firma www.makasy.com ... Compiler verhält sich bei VB6-Source-Input nahezu kompatibel. ... Implementierungen relativ elegant möglich (ohne viel Code ... Soviel erstmal zur prinzipiellen Arbeitsweise der neuen ...
    (microsoft.public.de.vb)
  • Re: Nette Features in C# 3.0
    ... >> Libraries) anpassen und nicht nur das Backend. ... Den Code, *den der Compiler benutzt, um meine Binaries für das ... >> Was auch immer Du da tust, es ist kein Compiler. ... Next try. ...
    (de.comp.lang.misc)
  • Re: Grundsatzfrage zum Klassen-Design
    ... Dass, wenn sich Tabellen ändern, sowohl Du als auch ich in den Code ... Sicherlich haben Interfaces ihren Zweck. ... den Compiler zum Generieren von Fehlermeldungen zu bewegen. ... weil mich SPs nun endgültig auf eine DBE festnageln. ...
    (microsoft.public.de.german.entwickler.dotnet.csharp)
  • Re: Bankswitching!
    ... Das macht alles der Compiler. ... und dann kann man zwecks Optimierung normalerweise seinen Code ... > globale Variablen und je eine Bank pro Modul für lokale. ... | Banking optimization removes MOVLB instruction in instances where it ...
    (de.comp.lang.misc)
  • Re: Migration auf .NET - Winform or WPF or Silverlight or ?
    ... Classic VB war im Laufe seines Lebens in vielerlei Hinsicht sogar recht fortschrittlich, ... Dass den Compiler keine Struktur interessiert, wenn die Syntax richtig angewandt wurde, ist die Grundlage dafür, dass der Compiler überhaupt funktioniert. ... Idealerweise könnte man im VB7 bestehenden Code 1:1 weiterverwenden und zugleich von .NET Framework wie in VB.NET Gebrauch machen. ... Ich warte nur darauf, bis dereinst Code, der z.B. von WPF oder LINQ Gebrauch macht, a-posteriori als Sünde abgestempelt wird, weil es dafür keinen direkten Migrationsweg gibt. ...
    (microsoft.public.de.vb)