Es existiert eine große Vielfalt an Programmen und Algorithmen – nicht minder groß ist die Vielfalt an verschiedenen Programmiersprachen. Und genau wie bei gesprochenen Sprachen besteht oft der Bedarf, einen Quelltext aus einer Programmiersprache in eine andere zu übersetzen.

Inhalt

	Konvertierung
	Sprachen und Konverter im Detail
	Fazit

Ein Programmcode ist letzendlich die konkrete Darstellung eines abstrakten Sachverhalts bzw. einer Handlungsanweisung in einer für Programmierer und Computer verständlichen Form: Einer Programmiersprache. Dementsprechend ist es möglich, ein Problem in verschiedensten Sprachen zu formulieren. Der Algorithmus kann vom Programmierer gelesen werden und wird dann in der Zielsprache neu geschrieben. Das erfordert zumindest grundlegende Kenntnisse in beiden Sprachen.
Wie sie allerdings sicher schon bemerkt haben, gibt es in Quellcodes immer die selben, wiederkehrenden Elemente – Schleifen, Variablen, Bedingungen, Funktionen. Kann nicht einfach ein Programm die Quellcodes automatisch umwandeln?
Prinzipiell Ja - Es existieren automatische „Source-Converter“, genau wie automatische Übersetzer für Sprachen wie Deutsch oder Englisch existieren, und genau wie diese ist ihr Erfolg schwankend – Hier ein paar Dinge, die zu beachten sind:

Um zwei Sprachen gut ineinander konvertieren zu können, sollten ein paar Bedingungen eingehalten werden.

• Die Sprachen sollten einen ähnliches Grundkonzept (man spricht von Programmierparadigma) verfolgen.
  Beispielsweise „ticken“ C und Pascal auf ähnliche Weisen, Haskell und Visual Basic allerdings nicht.
• Die Sprachen sollten vom Aufgabenbereich ähnlich sein – Eine Programmiersprache, die auf die Gestaltung von Websites
  ausgelegt ist, wird sich mit Aufgaben einer Sprache zum Bearbeiten mathematischer Formeln schwer tun.
• Die Sprachen sollten von ihren technischen Möglichkeiten ähnlich sein. Hierunter zählen Mechanismen wie generische Typen,
  Klassen bzw. Vererbung, Zeiger und der Umfang der Sprachbibliotheken. Hier offenbart sich z.B. ein Problem bei
  Umwandlungen von C++ nach VB, da ersteres ungleich mächtiger ist

Nach diesen eher allgemein gehaltenen Aussagen gehe ich nun noch auf zwei häufig anzutreffende Spezialfälle beim Konvertieren und ihre Problematiken ein.

VB .NET <-> C#

Die .NET-Sprachen bilden zum oben genannten eine sehr interessante Ausnahme - sie bauen auf fast identischer Technologie mit fast
identischen Sprachmitteln und Aufgabenbereichen auf. Wenn man VB und C# einmal im Vergleich betrachtet, sieht man, dass die Unterschiede
überwiegend syntaktischer Natur sind. In folgendem Beispiel ist jede Zeile 1:1 übertragbar.

Imports System

Class Fibonacci

    Public Shared Sub Main()
        Dim a As Integer = 0
        Dim b As Integer = 1

        For i As Integer = 1 To 12
            b += a
            a = b - a

            Console.WriteLine("{0}. Fibonacci-Zahl: {1}", i, a)
        Next

        Console.ReadKey()
    End Sub

End Class

using System;

class Fibonacci {
                
    public static void Main() {
        int a = 0;
        int b = 1;

        for (int i = 1; i <= 12; i++) {
            b += a;
            a = b - a;

            Console.WriteLine("{0}. Fibonacci-Zahl: {1}", i, a);
        }

        Console.ReadKey();
    }

}

Quellcode zwischen den einzelnen .NET-Sprachen hin- und herzuübersetzen ist gewolltermaßen ohne Weiteres auch maschinell möglich (F# bildet hier eine Ausnahme).
Man kann zunächst den .NET-Reflector benutzen, um analysierten Quellcode in verschiedensten Sprachen anzeigen zu lassen.
Es existieren aber auch zahllose Online-Konverter, in die man unkompliziert den Ausgangscode eingibt und gleich die fertige Übersetzung herausbekommt. Als Beispiel sei hier dieser Converter von DeveloperFusion genannt.
Der Unterschied zwischen beiden Verfahren ist, dass der Reflector aus bereits kompiliertem Code durch eingehende Analyse auf die Darstellung in den einzelnen Sprachen schließt, während die Online-Tools lediglich die eine Syntax in die nächste überführen. Vorteil hierbei ist, dass auch nicht kompilierfähige Schnipsel konvertiert werden können. Die Ausgabe beider Tools stimmt dabei zum Großteil. Nichtsdestotrotz gilt es beim Konvertieren Folgendes zu beachten.

• VB und C# haben trotz allem noch Unterschiede, Sprachfeatures, die in der jeweils anderen Sprache nicht existieren. Je nachdem, wie tiefgreifend diese sind, kann ein Übersetzer hier erhebliche Probleme haben. Aus einer Forendiskussion bezüglich einer möglichst vollständigen Liste der Unterschiede ist diese freie Online-Tabelle entstanden, die sie gerne auch um neue Punkte erweitern dürfen.
  Ein Auszug wichtiger Unterschiede:
  
  

  Nur VB	Nur C#
  WithEvents-Deklarationen	Generatorfunktionen per yield return
  Integrierte XML-Schreibweise	Aufzählungs-Initialisierer
  Der My-Namespace	Automatisch generierte Properties
  Option Explicit/Strict Off	Mehrzeilige anonyme Funktionen
  Benennung von Schnittstellenmethoden	Anonyme Prozeduren
  With-Blöcke	Unchecked-Blöcke
  Statische lokale Variablen	Zeiger / Unsicherer Code

  
  
  
• Für Tools, die den Code nicht kompilieren, existieren uneindeutige Fälle, die aus rein syntaktischer Betrachtung nicht entscheidbar sind. Beispiele:
  
  

  Aufruf	Uneindeutigkeit	_
  VB: xyz(42)	C#: Array-Zugriff?	xyz[42];
  _	C: Funktionsaufruf?	xyz(42);
  C#: xyz(Name);	VB: Variable?	xyz(Name)
  _	VB: Funktionszeiger?	xyz(AddressOf Name)

VB Classic (VB 5/6 oder früher) <-> VB .NET

Bei VB Classic und VB .NET verhält sich die Situation genau umgekehrt. Das einzige, was beide Sprachen noch verbindet, ist die ähnliche, oft gleiche Syntax – Vom ganzen Konzept, Aufbau, ihren Programmiermitteln und ihrer Mächtigkeit sind beide Sprachen aber grundverschieden. Dies macht es ungleich schwieriger, ja fast unmöglich macht, ganze Projekte schnell oder sogar automatisiert zu übertragen.
In klassisches VB zu übersetzen ist schwierig, da ein Großteil der mächtigereren Sprachmerkmale von VB .NET dort nicht existieren – Objektorientierung, Vererbung, Reflexion, Delegaten ... Und was noch viel wichtiger ist: Man hat das gesamte .NET-Framework nicht zur Verfügung, auf das VB .NET so sehr aufbaut. In die andere Richtung ist eine Konvertierung noch eher möglich, allerdings erhält man keinen Code, wie man ihn in .NET schreiben würde. Außerdem wird in VBC maschinennäher und extrem API-orientiert programmiert, Dinge, die in .NET entweder unnötig, unschön oder gar verboten wären.
Die Überlegung, die man anstrengen müsste, bevor man Quellcode tatsächlich konvertiert, wäre, ob sich ein komplettes Neuschreiben nicht eher lohnt. Auch besteht noch die Möglichkeit, beide Sprachen unabhängig miteinander interagieren zu lassen. .NET-Typen können als zu VBC kompatible COM-Typen exportiert werden (siehe  COM-Komponenten mit .NET schreiben [.NET-Tipp 0007]), während existierende DLL's oder Steuerelemente in .NET-Anwendungen
ebenfalls weiter unterstützt werden.

An mancher Stelle muss man auch einfach zu dem Schluss kommen, dass beide Sprachen zu verschieden sind und dass es einen Grund hat, weshalb ein Projekt in eben dieser Sprache geschrieben wurde – Ein Konvertieren ist nicht sinnvoll. Und selbst wenn die Sprachen rein technisch „passen“: Programmiersprachen haben auch immer eine eigene Philosophie; aus einer Umwandlung kann zwar syntaktisch 100%ig korrekter und ausführbarer Code resultieren, doch ist er nicht so, wie man ihn in der Zielsprache schreiben würde, ähnlich wie wenn man deutsche Sätze wörtliche ins Englische zu übertragen sucht. Soll ein Algorithmus konvertiert werden, ist oftmals doch das manuelle Übersetzen im Sinne eines Neuentwerfens das Beste. Man sollte jedoch auch die Möglichkeit in Betracht ziehen, existierende Codes und Komponenten über spezielle Schnittstellen interagieren zu lassen, anstatt sie alle umzuwandeln.