„Diskussion:Compiler“ – Versionsunterschied

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Compiler“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Automatische Archivierung

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

Archiv

ab 2004

Wie wird ein Archiv angelegt?

Quelltexte

Was sollen diese beiden ewig langen Abschnitte, in denen nur Quelltexte stehen? --DF5GO 01:39, 25. Dez. 2011 (CET)

1. Das hier war wohl eine Art Weihnachtsgeschenk. Sieht nach einem Grundkurs an der Uni aus, oder LK. Vielleicht funktioniert es ja, aber dann erst fertig schreiben, und richtig formatieren und abschnittsweise kommentieren. Und dann eher Wikiversity als Wikipedia.
2. Der kleine Beispielcompiler gehört zum Bestand, hat eine Einleitung sowie Beispiele zum Nachverfolgen und den generierten Beispieloutput. Das ist ja okay.

Ich hab dann mal aufgeräumt. --PerfektesChaos 11:03, 25. Dez. 2011 (CET)

Ist immer noch ziemlich viel Quelltext. Soviel auf jeden Fall, dass ich nicht komplett verstehe, was das Programm tut. Liegt aber wohl auch daran, dass der Quelltext komplett unkommentiert ist. --DF5GO 03:31, 26. Dez. 2011 (CET)

Sorry - aber so kann der Quelltext nicht stehenbleiben. Wenn wer einen Mini-Compiler wo findet, der in 10-20 Zeilen Code was compiliert, dann gerne - aber das hier ist einfach viel zu lange. Ich hab mal die Funktionalität des Compilers reduziert - der Source ist aber immer noch 74 Zeilen lang. Ich denke der Artikel Compiler (und auch Interpreter) braucht keinen Sourcecode den Sachverhalt zu erklären - im Gegenteil, Sourcecode verwirrt hier nur. --Sebastian.Dietrich ✉ 10:33, 26. Dez. 2011 (CET)

Wer Vieles bringt, wird manchem etwas bringen.

Der Artikel richtet sich an Schüler, Studies, PC-Interessierte. Weil ein Foto eines Compilers den Artikel kaum illustrieren könnte, ist ein einfacher Beispielcode für ein verallgemeinerbares Grundproblem sehr sinnvoll und sollte unbedingt erhalten bleiben. Ich habe den existierenden Beispielcode jetzt nicht allzusehr geflöht; mir scheinen aber auch noch ein paar für den Profi triviale, für beginners hilfreiche Kommentare im Quellcode oder umschließenden Text ergänzbar, und seien es nur die deutschen Übersetzungen für die Namen der Unterprogramme. Ansonsten ist das existierende Beispiel didaktisch wohl ganz brauchbar. Und da ganz, ganz hinten stört das auch keinen Lesefluss. Noch kürzer als diesen Übersetzer für arithmetische Ausdrücke wird man ein sinnvolles Beispielprogramm nicht hinkriegen. Und eine Verwirrrung sehe ich unmittelbar vor dem Literatur&Weblink-Anhang in keiner Weise; wer es nicht mag, liest halt nicht weiter.

Soviel für 2011 --PerfektesChaos 21:05, 26. Dez. 2011 (CET)

Die Wikipedia richtet sich aber nicht nur an Schüler, Studies, PC-Interessierte, sondern auch an Laien. Dementsprechend sollte der Artikel auch aufgebaut sein, Stichwort Laientest. Und das beinhaltet imho auf jeden Fall, dass ein Quelltext ausführlich kommentiert sein sollte, genauso wie ein Bild auch eine vernünftige Bildbeschreibung haben sollte. --DF5GO 00:27, 27. Dez. 2011 (CET)

und in jedem Fall ist dieses Beispiel zu kompliziert und deshalb für Laien unverständlich. Hier wird eine Stapelmaschine auf ziemlich undurchsichtige Weise verwendet. Eigentlich sollte der Code

       5+3*2-9

so übersetzt werden:

        PUSH 5
        PUSH 3
        PUSH 2
        MUL
        ADD
        PUSH 9
        SUB

Der Code des Compilers würde dementsprechend auch einfacher. --Herbert Klaeren 10:18, 27. Dez. 2011 (CET)

Da sich hier seit knapp zwei Wochen nichts getan hat, habe ich den Artikel mal bei der Qualitätssicherung der Redaktion Informatik eingetragen. --DF5GO 13:12, 7. Jan. 2012 (CET)

WP:OMA möchte vor allem, dass Laien beim Lesen des Artikels verstehen, um was es im Groben geht. Es ist nicht notwendig, dass sie alles verstehen. Der QS-Eintrag ist daher völlig überflüssig.

Davon abgesehen ist der hier diskutierte Abschnitt keine Hilfe für irgendeinen Leser. Und das liegt nicht an der fehlenden Kommentierung. Das Lemma ist schlicht ungeeignet für konkrete Beispiele. Zumal der Quellcode in den Artikel Tokenizer gehört, wenn überhaupt irgendwohin! Das trifft im Übrigen auch auf die weiter oben befindlichen Codebeispiele zu. Hier sollte eher mit Ablaufdiagrammen gearbeitet werden als mit Beispielcode. Evtl. ist ein (ganz!) kleines Beispiel in ANTLR mit In- und Output hilfreich, weil das am leichtesten die Funktionsweise eines Compilers klar macht. Aber das ist purer Luxus.

Was dem Artikel fehlt, sind Erklärungen über die Bestandteile und die Funktionsweise von Übersetzern, Parser, Parserkonzepte (Top-Down/Bottom-Up/einfach/mehrfach/Präcompiler), Lexer, Formale Grammatiken. Die momentan dort vorhanden Teile sind ziemlich dünn. Aber auch das ist definitiv nicht laientauglich. --Trac3R 14:09, 7. Jan. 2012 (CET)

Also meinetwegen kann das Beispiel auch raus. Aber wenn es drin bleibt, dann muss es auch ordentlich kommentiert sein. --DF5GO 11:50, 11. Jan. 2012 (CET)

Wenn es drin bleibt, dann ist es dennoch im falschen Artikel. Im Artikel Tokenizer kann man sicher die Funktion an einem abstrakteren und kürzeren Beispiel erklären. Ebenso wie man die Funktion einer syntaktischen Prüfung im Artikel Parser klären kann. Ein lauffähiges Beispiel wie dieses ist total überflüssig und führt zwangsläufig zu einem unverständlichen Artikel. --Trac3R 12:28, 11. Jan. 2012 (CET)

Ok, was machen wir jetzt? Da ich fachlich nicht in der Lage bin, das Beispiel zu verständlich zu machen, aber es auch sonst offenbar niemand bereit dazu ist, das verständlich zu machen, wäre ich für löschen des Beispielquelltextes. --DF5GO 13:11, 11. Jan. 2012 (CET)

meinen Segen hast du dazu... --Herbert Klaeren 13:13, 11. Jan. 2012 (CET)

Ich hab das Beispiel jetzt durch ein formaleres ersetzt. Ob das jeder versteht bezweifle ich jedoch, es macht allerdings die Funktionsweise der einzelnen Komponenten besser sichtbar und ist kommentiert. --Trac3R 17:23, 11. Jan. 2012 (CET)

erledigtErledigt Das Beispiel ist deutlich besser. Bin bei weitem kein Programmierexperte, aber durch die Kommentare kann ich zumindest ungefähr nachvollziehen, was das Programm tut. Das alte Programm hingegen hab ich nicht ansatzweise verstanden. Insofern eine deutliche Verbesserung. --DF5GO 17:49, 11. Jan. 2012 (CET)

Anderer Beispiel-Compiler

es geht wirklich komplett billig. Ihr könnt euer Drachenbuch grad nehmen und in die Tonne treten. Ihr gebt hier einen simplen Term ein, und das Programm übernimmt das Raufsortieren. Je höher die Priorität des Operators, desto weiter oben. Danach geht's nach der Operatorerkennung direkt zu Assembler. Mit einfachen Uebersetzungsregeln. Für die Kontrollstrukturen (if, while, for,... ) fügt ihr ein cmp ein, legt einen Stack an und holt bei der geschlossenen geschweiften Klammer die jmp-Sprungmarke vom Stack. Es geht wirklich nicht schwer. Löst Algebra auf, und überlegt, was ihr dabei macht.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static int var_name_count=0;

void variable_countup(char *name, int do_countup)
{

 char appendix[255];
 char *base="rptr";
 if ( do_countup == 1 ) ++var_name_count;
   itoa(var_name_count, appendix, 10);
   
 strcpy(name,base);
 strcat( name, appendix );
 return ;

}


void prepare_input( char *string)
{
 while ( *string != '\0' )
 {
  if ( *string==' ' )
  {

   string++;
   while ( *string==' ' ) strcpy(string-1, string ), string++;

  }
  string++;
 }

}

int token_in_range( char *string, int len, char token, int *token_pos )
{
  int count=0;
  while (string[count]!= token )
  {
    count++;
   if ( count> len ) return 0;

  }
 *token_pos=count;

  return 1;
}

int seek_to_variable_in_range_downwards(int *pointer, char *string, int start )
{
 while ( string[*pointer]==' ' && *pointer > 0) (*pointer)--;
 if (  ! isalnum( string[*pointer] ) )return 1;

 while (  isalnum ( string[*pointer] ) &&
          *pointer >= start )
          {

            (*pointer)--;
            }
            (*pointer)++;
 return 0;
}


int seek_to_variable_in_range_upwards(int *pointer, char *string, int len )
{
 while ( string[*pointer]==' ' && *pointer < len ) (*pointer)++;
   if ( ! isalnum (string[*pointer] ) )return 1;
 while (  isalnum( string[*pointer] ) &&
               *pointer <= len )
               {
            (*pointer)++;

               }
               (*pointer)--;

 return 0;

}


int main(void)
{

 char input[255];
 char result_string[255]="";
 char end_of_input[255];
 char var_name[255];

 int abort=0;
 int noops=0;
 int start, start_seek, start_seek_b, end, end_seek, token_pos;
 
 gets(input);
 prepare_input(input);
 
 start=0;
 end=strlen(input);
 
 
 while (noops==0)
 {
  noops=1;
  end=strlen(input);
  start=0;

     /* zum Funktionsaufruf eingrenzen */
  if( token_in_range(input, end,')', &token_pos )==1 )
  {
   noops=0;
   end_seek=start;
   while( input[end_seek]!=')' ) end_seek++;
   start_seek=end_seek;
  
    if ( token_in_range( input, end_seek, '(', &token_pos ) )
   {
    while(input[start_seek]!='(' ) start_seek--;
    if (start_seek > 0 ) start_seek--;
    if ( seek_to_variable_in_range_downwards(&start_seek, input, start)==0 )
   {
    end=end_seek;
    start=start_seek;
   }
  }

  }
 



   /* zu den Klammern eingrenzen */

   if( token_in_range(input, end,')', &token_pos )==1 )
   {
    noops=0;
    end_seek=start;
    while( input[end_seek]!=')' ) end_seek++;
    start_seek=end_seek;
  
     if ( token_in_range( input, end_seek, '(', &token_pos ) )
    {
     while(input[start_seek]!='(' ) start_seek--;
    }
     else
     {
      printf ("Syntaxfehler: geschlossene Klammer fehlt.\n");
      abort=1;
     }
     if ( ! abort )
     {
       start_seek_b=start_seek-1;
     if ( seek_to_variable_in_range_downwards(&start_seek_b, input, start)==1 )
     {
      end=end_seek;
      start=start_seek;
     }
    }

   }

    /* zum Multiplikations- oder Divisionsoperator eingrenzen */
   
  if ( token_in_range ( input+start, end-start, '*', &token_pos ) ||
       token_in_range ( input+start, end-start, '/', &token_pos )    )
  {
    noops=0;
    
    start_seek= start+token_pos;
    end_seek= start+token_pos;
     
     start_seek--, end_seek++;
     if( seek_to_variable_in_range_downwards(&start_seek, input, start)==1 ||
     seek_to_variable_in_range_upwards(&end_seek, input, end)==1 )
     {
      printf("Syntaxfehler bei Multiplikation oder Division.\n"); abort=1;
     }
     else
     {
      end=end_seek, start=start_seek;
     }

  }

if (abort==1 ) return;
   /* zum Additions- oder Subtraktionsoperator eingrenzen*/
   
  if ( token_in_range ( input+start, end-start, '+', &token_pos ) ||
       token_in_range ( input+start, end-start, '-', &token_pos )    )
  {
    noops=0;
    
    start_seek= start+token_pos;
    end_seek= start+token_pos;
     
     start_seek--, end_seek++;
     if( seek_to_variable_in_range_downwards(&start_seek, input, start)==1 ||
     seek_to_variable_in_range_upwards(&end_seek, input, end)==1 )
     {
      printf("Syntaxfehler bei Addition oder Subtraktion.\n"); abort=1;
     }
     else
     {
      end=end_seek, start=start_seek;
     }

  } 

if ( abort==1 ) return;
/* Raufsortieren und Substring ausm String loeschen */

if ( noops==0)
{
  strncat( result_string, input+start, end-start+1);
  strcat( result_string, "=");
  variable_countup(var_name,1);
  strcat( result_string, var_name);
  strcat( result_string, "\n");

  strcpy (end_of_input, input+end+1);
  strcpy (input+start, var_name);
  strcpy( input+start+strlen(var_name), end_of_input);

  }

 }

  strcat(result_string, input );
 printf("%s", result_string);
 getch();
 return;

}

(nicht signierter Beitrag von 109.43.181.76 (Diskussion) 01:32, 25. Apr. 2012 (CEST))

1. Als "neuer Beitrag" von mir ans Disku-Ende verschoben.
2. Sourcecode gehört umrandet mit

   <syntaxhighlight lang="c" />
   

   ,

   <source lang="c" />
   

   ,

   <code />
   

   oder ähnlichem.
3. Unterschrieben war's auch nicht.
4. Keine Überschrift.

 *grummel* --arilou (Diskussion) 09:26, 25. Apr. 2012 (CEST)

Inhaltlich kann ich hierzu NULL sagen. Nur soviel: Was da gezeigt wird, kann nie im Leben der Code eines Compilers sein. Das sind höchstens irgendwelche Parameter, die von einem wirklichen Übersetzerprogramm interpretiert werden. Ein Compiler braucht im einfachsten Fall Lesebefehle für Quelltextzeilen, müsste Algorithmen zum Umsetzen von symbolischen in physikalische Adressen haben, müsste Befehlscode konvertieren in Maschinenbefehlscode, Write-Befehle für die Ausgabe des Maschinencodes aufweisen, Fehlerhinweise bei Syntaxfehlern ausgeben etc. etc. Von all dem 'sieht' man hier nix.
Also: Liege ICH da falsch? Oder verstehe ich gar nichts von Compilern? Die OMA jedenfalls wird diesen Code keinesfalls mit dem geschriebenen Text in Einklang bringen können. Vielleicht ist nur die Kapitelüberschrift 'Ein Beispielcompiler' unpräzise. --VÖRBY (Diskussion) 19:54, 4. Aug. 2012 (CEST)

Ich hatte auf das Ding schon mal oben unter #Quelltexte reagiert, Stichwort „Weihnachtsgeschenk“.

Es ist irgendwo mit C&P abgekupfert; vermutlich funktioniert es sogar.

Es ist tatsächlich ein Compiler, der arithmetische Ausdrücke (vier Grundrechenarten und Klammern, sowie Variablennamen und Wertzuweisung) übersetzen kann.

Die Zielsprache ist nicht programmiert. Assembler-Code könnte man zumindest aus der Auswertung des Resultats dieser Angelegenheit generieren und dann irgendwas damit ausrechnen.

Eigentlich ist das aber mehr ein Parser. Gleichwohl: Genau sowas wird beim Zwischencode=Bytecode verwendet. Lisp nennt sein Gebilde für Bytecode auch Compiler (byte-compile), zumindest in denjenigen von 100 Dialekten, die mir bislang untergekommen sind; und in Java heißt das javac für Java-Compile. Dieses Dings hier übersetzt die in menschenlesbarer, formatierter Sprache vorliegende Zeichenkette in die maschinengeeigneten Brösel und formale Beziehungen dazwischen. Jetzt könnte man die Abfolge der Brösel den Assembler-Befehlen zuordnen, oder den Zwischencode-Syntaxelementen.

Für unseren Artikel ist das eh nix; ich glaube, vor einem Jahr hatte da mal ein anderer „Beispielcompiler“=Parser dringestanden.

Hoffe geholfen zu haben --PerfektesChaos 22:11, 4. Aug. 2012 (CEST)

Danke, ich verstehe das dann so: Der gezeigte Code ist tatsächlich 'Quellcode' für einen (fiktiven) „Compiler“. In welcher 'Programmiersprache' ist dieser Code formuliert? Wie jeder Quellcode wird auch dieser von einem (anderen) Compiler/Interpreter übersetzt und das Ergebnis letztlich als Maschinencode bereitgestellt bzw. ausgeführt (wie das ebenfalls immer ist). Hier wären also zwei Compiler-Ebenen 'im Spiel'. Die von mir vermissten Funktionen müssten dann in der zweiten Compiler-Ebene angesiedelt sein, werden dort standardmäßig durchgeführt - und sind hier im Code nicht sichtbar. Richtig? (Zuviel Diskussion will ich aber hiermit nicht auslösen.) Grüße von --VÖRBY (Diskussion) 09:38, 5. Aug. 2012 (CEST)

Ich habe das Progrämmle nicht kompiliert und damit herumexperimentiert, aber vom Drüberlesen passiert gefühlsmäßig etwa Folgendes:

• Eingabeformat: Arithmetischer Ausdruck in menschenlesbarer Form, wie

17 * (5 + 19 + 36) + 28*(96+14-18) + 654

• Ausgabe: Zurzeit ebenfalls menschenlesbar; Einzelanweisungen sortiert wie ungefähr

            v0=17
            v1=5
            v1=v1+19
            v1=v1+36
            v0=v0*v1
            v1=28
            v2=96
            v2=v2+14
            v2=v2-18
            v1=v1*v2
            v0=v0+v1
            v0=v0+654

oder so ähnlich. v0 ist das Ergebnis.

In den letzten zehn Statements des Programms stehen die Ausgabeanweisungen für zurzeit menschenlesbare Sprache. Hier könnte man aber genausogut die Statements irgendeines Assemblers einsetzen, und dann hätte man einen Compiler für arithmetische Anweisungen nach Assembler (was fast schon Maschinencode ist, nur in menschlicher Notation). Man kann auch im Handbuch für die CPU seines Vertrauens die Kodierungen für Operationen und Registerzuweisungen nachgucken und diesen in den Ausgabeanweisungen benutzen; dann wäre es echter Maschinencode.

Entscheidend ist, dass dieser Parser-Compiler in seinen internen Speichern die Syntaxbrösel, Zahlen und Operatoren in der richtigen Beziehung hält; aus diesen kann man in jedem beliebigen Format Bytecode, Assembler oder Maschinensprache ausgeben.

Sowas wird vielleicht in der 11. Klasse bei einem guten Informatik-Kurs gemacht, oder die Schüler sollen es selbst in Pascal schreiben. Irgendwo aus so einer Ecke ist das auch abgekupfert. Für unseren Artikel zu gaga, auch wenn wir über Jahre irgendwelche ähnlichen Codes im Artikel hatten.

Schönen Sonntag noch --PerfektesChaos 16:25, 5. Aug. 2012 (CEST)

Herzlichen Dank nochmal für deine Mühe. Trotzdem verstehe ich (und sicher auch meine OMA!) nur Bahnhof. Zum Beispiel kann ich überhaupt nicht erkennen, wo dieser Compilercode feststellt, wo die Klammern gesetzt sind oder wo/wie die Punkt-vor-Strich-Regel implementiert ist. Oder wie festgelegt ist, dass die Zeilen des späteren Quellcodes gelesen werden, wo und wie die Syntaxprüfung stattfindet oder dass/wie die Ausgabebefehle erzeugt oder eine Liste erstellt würde. Nach meinem Verständnis ist das also nicht der „Quellcode eines Compilers“, sondern es sind nur Angaben, die ein 'Compiler-Compiler' nach einer festgelegten Syntax interpretiert und anhand dieser Angaben den Maschinencode für einen (einfachen) Compiler erzeugen kann. Der 'Löwenanteil' der dazu erforderlichen Funktionalität steckt NICHT in dem hier gezeigten Code, sondern ist im Compiler-Compiler (nicht sichtbar) programmiert - der nach meinem Verständnis 'der Compiler' wäre - dessen Quellcode hier nicht gezeigt wird.
Insofern wäre die Überschrift m.E. nicht ganz korrekt - oder ich bin blind für die 'Wunder', die DIESER 'Compiler' vollbringen kann (Maschinencode für Dinge erzeugen, die nirgends sichtbar sind). Damit wollen wir es aber nun belassen. Danke nochmal. --VÖRBY (Diskussion) 18:39, 5. Aug. 2012 (CEST)

Vielleicht doch noch die 'Erleuchtung' meinerseits? Ich denke, man muss verschiedene Generationen von Compilern unterscheiden. Meine vorgenannten 'Einwände' basieren auf dem Verständnis für einen konventionellen (2-3-GL?) Compiler. Wenn man aber unterstellt, dass auch bei der Anwendungsentwicklung, z.B. über einen Reportgenerator, der 'Quellcode' auch nicht zeigt, dass/wo Daten gelesen und Zeilen gedruckt werden, dann kann das genauso auch bei Compilern sein: Der gezeigte Code wird von einem Compiler-Programmierer erzeugt, der diesen Code als 'Compiler-Quellcode' bezeichnet - wie der Anwendungsprogrammierer die Reportspezifikation. Beide werden von 'tiefer liegenden' Softwareschichten verarbeitet, und führen zum beabsichtigten Zweck, einem Report bzw. einem Compiler.

Nun will ich es aber wirklich gut sein lassen. Ob 'man' den Text diesbezüglich präzisieren sollte, kann ich nur schwer beurteilen. --VÖRBY (Diskussion) 13:07, 6. Aug. 2012 (CEST)

WAS tut ein Compiler?

Hallo im Artikel suche ich vergebens danach, was ein Compiler konkret tut. Mit den einzelnen Phasen wird zwar ausführlich beschrieben, WIE er das tut - aber eben nicht WAS. Ich meine damit die aktuell hier beschriebenen Aspekte. Leider auch ohne Belege und ohne Garantie auf Vollständigkeit. Sollte man den Abschnitt von dort einfach hier einfügen? --VÖRBY (Diskussion) 12:47, 4. Aug. 2012 (CEST)

Die ersten zwei Sätze sagen es doch sehr schön. --Chricho ¹ ² ³ 18:39, 4. Aug. 2012 (CEST)

'Sehr schön' ist leider nicht sehr klar, denn das ist nur die pauschale Aussage 'Übersetzen'. Was das konkret ist, wird da nicht erklärt. Hattest du den obigen Link aufgerufen? Hättest du dazu konkretere Informationen? --VÖRBY (Diskussion) 19:40, 4. Aug. 2012 (CEST)

In der Tat, hatte ich nicht angeklickt, sorry. Das (was dort steht) ist aber auch ziemlich unerheblich dafür, was prinzipiell ein Compiler ist. Gehört daher keineswegs in die Einleitung oder zu einer Definition o. ä. --Chricho ¹ ² ³ 14:36, 5. Aug. 2012 (CEST)

Für die Definition würde ich das auch nicht verwenden. Trotzdem werden WP-Artikel üblicherweise zusätzlich zur Definition durch weitere (wesentliche) Details ergänzt. Und sowas würde ich hier einfach auch suchen, ggf. als erstes Unterkapitel von 'Details' - denn das ist auf jedenfall 'essentieller' als die Wahlfunktionen der 'Optimierung'. --VÖRBY (Diskussion) 14:43, 5. Aug. 2012 (CEST)

Ich habe diese Teilfunktionen (wie auch andere Detailtexte zu 'Übersetzer') aus dem Artikel Programmiersprache HIER eingefügt. Dort sollen solche Details nicht stehen, sondern über einen Hauptartikelverweis verlinkt werden (in Bearbeitung). --VÖRBY (Diskussion) 19:58, 6. Aug. 2012 (CEST)

Also mit dem, was jetzt in der Einleitung steht, bin ich nicht so glücklich. So ein C-Präprozessor ist zweifelsohne ein Compiler für eine gewisse Sprache, und überhaupt erscheint mir das viel zu speziell für die Einleitung. Das ist dann eher spezieller Jargon, dass man im Kontext eines Builds nur einen ganz bestimmten Schritt als eigentliches Kompilieren bezeichnet. Zur Klärung des allgemeinen Compilerbegriffs trägt das nichts bei. --Chricho ¹ ² ³ 01:18, 7. Aug. 2012 (CEST)

Hm, ein Präprozessor ist imo kein Compiler. Präprozessor-Anweisungen werden nicht "übersetzt", sondern ausgeführt, indem die entsprechenden Quellcode-Umbauten durchgeführt werden. Insofern kommt ein Präprozessor eher einem Interpreter gleich, der den Input (C-Quellcode) gemäß eingebetteter Anweisungen umbaut und als Output nun reinen C-Code weitergibt. --arilou (Diskussion) 11:31, 7. Aug. 2012 (CEST)

Die neue Ergänzung in der Einleitung erläutert eine frühere Bedeutung von 'Compiler'. Insofern ist das in der Einleitung richtig angesiedelt. Ob dann die beiden Spielgelpunkte so stehen bleiben müssten, wäre eine andere Frage. Ich denke, das könnte man mit Fließtext an dieser Stelle besser beschreiben.--VÖRBY (Diskussion) 12:05, 7. Aug. 2012 (CEST)

Fortsetzung der Diskussion siehe nächster Abschnitt; gehört nicht mehr zur DIESER Fragestellung.

Zu viele Unterschiede

Fortsetzung vom vorherigen Abschnitt (letzter Absatz):

Hallo, zunehmende Beschäftigung mit dem Thema verursacht auch bei mir ein wenig 'Grummeln'. Meine Sicht: Es gibt offensichtlich zu viele Varianten für Compilereinsätze, als dass man das immer in einem Text beschreiben könnte.
Zum Beispiel betrifft das bisher die Sache mit Compiler vs Interpreter vs Zusatzlinker vs Preprozessor. Das führt ihrgendwie immer zu komplizierten Formulierungen wie 'Maschinencode oder Zwischencode', der Kompromiss 'Zielcode' wäre da auch nicht immer vorteilhaft.
Noch gravierender aber unterscheidet sich unser Lemma in Szenarien für klassische Sprachen (~imperativ) vs Übersetzung neuerer Anwendungen (~deklaratkiv, OO etc.). Als Beispiel will ich nur SQL oder eine Access-Anwendung anführen: Dort läuft doch das ganze Übersetzen total anders als z.B. bei Cobol. Der bisherige Text orientiert sich aber meist am klassischen Compilerbegriff bzw. ist diesbezüglich ein intransparenter Mischtext. Hier scheinen auch die Einwände von Chricho ihre Ursache zu haben.
Habt Ihr Vorschläge, wie man diese Unterschiede gut beschreiben und darstellen könnte? Eigene Artikel scheinen mir auch keine gute Lösung zu sein. Grüße von --VÖRBY (Diskussion) 09:13, 7. Aug. 2012 (CEST)

Sorry, kenn' mich nur mit der "klassischen Variante" halbwegs aus.

Im Moment seh' ich keinen sinnvolleren Weg, als die verschiedenen Varianten hier im Artikel aufzudröseln.

Vielleicht kommt die Erkenntnis ja dann. --arilou (Diskussion) 11:44, 7. Aug. 2012 (CEST)

Ich denke, es ist nicht zielführend, anzufangen, hier ganz spezielle Begrifflichkeiten zu wählen, die allerhand vom Compilerbegriff ausschließen, nur weil man die normalerweise bei einem anderen Namen nennt. Ein Präprozessor ist definitiv ein Compiler, die Sprache, die der übersetzt, ist aber eben so angelegt, dass das Quellprogramm den Kompilierungsvorgang recht direkt steuert, das ist bei zahlreichen Sprachen mit Metaprogrammierungsfähigkeiten nicht anders. Eine Sache, bei der man sich wohl entscheiden muss, ist, ob man nur die Software zählen lässt, die für den Weg zur Ausführung gedacht ist, oder allgemeine Übersetzer zwischen formalen Sprachen (was auch Decompiler einschließen würde). Das Drachenbuch unterscheidet zwischen compilers (erstes Ding, „But, before a program can be run, it first must be translated into a form in which it can be executed by a computer. The software systems that do this translation are called compilers“.) und „language translators“. Ein C-Präprozessor wäre aber zweifelsohne in beiden Fällen dabei, denn er ist nunmal kein Textverarbeitungstool sondern dient der Überführung in Richtung ausführbarer Code. Wie auch immer, wie ein Präprozessor heißt, ist gar nicht mal so wichtig: Diese (zwei Sätze vorher) begriffliche Unterscheidung müsste man in der Einleitung klar machen, nicht irgendwelche Spezialfälle. --Chricho ¹ ² ³ 12:03, 7. Aug. 2012 (CEST)

Deine Anmerkungen zeigen u.a. das Dillemma: Dein englisches Zitat schreibt '... which can be executed by a Computer'. Dann sagst du, ein C-Präprozessor gehöre 'zweifelsohne' dazu - und schreibst, dieser erzeuge Code 'in Richtung' ausführbarer Code. Das ist ein erheblicher Unterschied. Was die Einleitung betrifft, habe ich den Absatz umgetextet und hoffe, so passt es eher. Ansonsten zeigt auch diese Diskussion, dass im Artikel die dem Sachverhalt angemessene Struktur - die beim Leser Klarheit bringen würde - noch fehlt.--VÖRBY (Diskussion) 12:24, 7. Aug. 2012 (CEST)

Es geht darum, dass das letztliche Ziel eine Ausführung eines Programms ist, Zwischenstufen zählen natürlich auch. --Chricho ¹ ² ³ 12:35, 7. Aug. 2012 (CEST)

Klarheit in unser Lemma könnten einzelne Beschreibungen je Szenario sein. Ein Beispiel dafür:

Szenario IBM-Großrechner mit 3GL:

Der Compiler übersetzt den per Texteditor erzeugten, optional von einem Precompiler ergänzten Quellcode für genau ein 'Programm' (PGM X) und erzeugt dabei prozessorspezifischen Objektcode. Soll das Programm direkt vom Betriebssystem aufrufbar sein, so wird dieser Code mit dem Linkage Editor um sprachspezifische Module ergänzt und der Objektcode aller aufgerufenen Unterprogramme hinzugebunden. Ergebnis ist ein ausführbares Lademodul für das 'Programm X'. Für nicht getrennt aufrubare Unterprogramme wird nur der Objektcode erzeugt - der nur beim Linken der sie aufrufenden Programme verwendet wird. Siehe auch Grafik - könnte folgen.

Wäre das ein Ansatz? --VÖRBY (Diskussion) 19:53, 7. Aug. 2012 (CEST)

Nach dem Diskussionsstand, auch in den nachfolgenden Abschnitten, scheinen sich alle Beteiligten darin einig, dass der Artikel verbesserungsfähig ist. Als nächsten Schritt schlage ich vor, eine kleine ToDo-Liste zu führen, wo überall Veränderungen / Ergänzungen stattfinden sollten. Danach könnten wir feststellen, wer sich wofür kompetent fühlt und Textentwürfe zuerst diskutieren und dann in den Artikel übernehmen. --VÖRBY (Diskussion) 11:41, 9. Aug. 2012 (CEST)

ToDo's

Nachfolgend sind einige Stichworte (zum Teil in Frageform) aufgeführt, zu denen sich m.E. (VÖRBY) im Artikeltext bzw. den genannten Abschnitten Aussagen finden sollten. (bitte bei Bedarf entsprechend ergänzen / anpassen)

• Einleitung:
  • Erwähnen, dass sich der Begriff im Zeitverlauf und bedingt durch zahlreiche Veränderungen in der Computer- und Entwicklungsarchitektur ebenfalls stark verändert hat. >>ERL. VÖRBY s.u.
  • Klare Kriterien benennen, wonach man feststellen kann, was als Compiler gilt
    • Ist ein Interpreter eine 'Art von Compiler' oder eine 'Abgrenzung zu Compiler', also kein Compiler? Gilt das für beide Versionen von Interpretation (Befehle einzeln bzw. en-bloc)?
    • dto: für Linker geltend
    • dto: für beide Stufen bei Erzeugung von Zwischencode bzw. Maschinencode daraus?
    • dto: nur wenn Maschinencode erzeugt wird oder bei jeder Übersetzung 'in Richtung' Maschinencode/Ausführung? Was bedeutet die bisherige Formulierung 'Insbesondere ... Maschinencode' für die Definition?
  • Evtl. erwähnen, dass man den Begriff nach engerer (z.B. Maschinencode erzeugen) oder nach weiterer Definition (jede Art von Konvertierung) interpretieren kann
• Übersetzungsszenarien:
  • Entsteht beim Kompilieren bzw. Interpretieren inhaltlich identischer Code oder 'etwas ganz anderes'? ERLED 16.8.: Jetzt Links auf AOT/JIT-Compilierung
  • Es gibt noch ein drittes Grundprinzip: Die Verwendung von Quellcode-Spezifikationen über Laufzeitsysteme - die weder Compilierung noch Befehls-Interpretation ist. ERLED 16.8.: Laufzeitumgebungen eingefügt
• Ablaufbeispiele: (konkrete Beschreibungen - neben den nur global/allgemein formulierten Übersetzungsszenarien):
  • Ergänzen weiterer relevanter Beispiele, zB. C, Java, LZ-Umgebung mit MS Access (ERL)
  • Allgemeine Beschreibung unter 'Übersetzungsszenarien' entsprechend verallgemeinert belassen / umformulieren ERLED 16.8.
• Sonstiges:
  • Gibt es Unterschiede zwischen imperativen, deklarativen, OO- und anderen Paradigmen (die Compilierung betreffend)? Evtl. sind das ~ die Unterschiede zwischen Laufzeitumgebung und Kompilierung??
• Belege für die wichtigen Aussagen im Artikel nachtragen

Diskussionen zu ToDo's

@VÖRBY: Ich probiere es mal mit einem Schwung Antworten.

Antworten von VÖRBY in small angefügt.

1. Interpreter. Das sind m.E. zu viele Details, ich hatte an grundsätzliche Unterschiede zwischen Interpretation und 'Compilierung' gedacht.
   • Das hängt alles sehr davon ab, was da ausgeführt werden soll.
   • Im Regelfall ist der Interpreter ein laufendes Anwendungsprogramm, das die interaktiv eingetippten oder über Skript/Stapel eintreffenden Statements einliest und nach jedem Statement die vorgesehene Aktivität entfaltet. >>Der I. ist ist doch immer ein laufendes Anwendungsprogramm.
     • Der Arm des Roboters kann gehoben werden oder ein Kringel kann auf den Bildschirm gezeichnet werden.
     • Ein Arithmetik-Programm könnte das Resultat von

       5 * 7 + 9 - x =

       nach Drücken von Enter auf den Bildschirm schreiben, oder als Wertzuweisung diese vornehmen:

       y = 5 * 7 + 9 - x

     • Bekannt ist der Kommandozeilen-Interpreter der verschiedenen Betriebssysteme (shell, console):
       • Jedes Statement fängt mit einem Befehlswort an, danach folgen optional spezifische Parameter.
       • Inspiziere bei jedem Statement zunächst das Befehlswort, ob es einem intrinsischen (eingebauten) Befehl entspricht, etwa set oder echo oder help und schließlich exit. Führe einen erkannten intrinsischen Befehl mit den Parametern aus (ggf. ein zugeordnetes System-Unterprogramm aufrufen). Auch Kontrollstrukturen wären im Skript-Modus denkbar.
       • Wenn Befehlswort unbekannt, durchsuche der Reihe nach die für ausführbare Programme vorgesehenen Dateipfade, ob sich darin eine ausführbare Datei befindet, deren Name dem Befehlswort entspräche. Wenn gefunden, führe dieses Programm mit den Parametern aus.
       • Wenn nichts gefunden, dann Fehlermeldung.
     • Analog ein SQL-Dialog, etwa mit dem guten alten dBase. Setze die Suche in der Datenbank um und führe ggf. Veränderungen aus; zeige Ergebnisse.
   • Was lernt uns das?
     • Es erfolgt nicht zwangsläufig eine Übersetzung in eine Maschinensprache oder eine ausführbare Programmeinheit. >> Doch, ALLES was auf dem Computer ausgeführt wird, ist - letztlich - Maschinencode!!
       – Nee. Siehe unten. Der Maschinencode ist schon längst vorhanden. /P.C.
     • Interpreter können sowohl nach imperativem wie auch nach deklarativem Paradigma tätig werden. Entscheidend ist die sofortige Umsetzung nach Fütterung.
2. Kompilieren.
   • Übersetze einfach nur in ein maschinennäheres Sprachniveau und hebe das Ergebnis hübsch auf; führe nichts aus.
3. Objektorientiert.
   • Das ist eher eine trickreiche und möglichst narrensichere Verwaltung, welche Funktion mit den Daten welchen Objekts ausgeführt werden soll. Sie hilft dem Menschen, den Durchblick zu behalten. Was letztlich ausgeführt wird, ist prozedural/imperativ; eine Funktion, gern auch Methode genannt: ein schlichtes klassisches Unterprogramm. >> Trotzdem: Läuft da beim Compilieren / Interpretieren etwas grundsätzlich anders? Was?
4. Prozedural, algorithmisch, imperativ:
   • Die Aktivitäten aus diesem Dunstkreis sind sehr ähnlich dem, was in weniger gut für Menschen lesbarer Form der Maschinencode ausführt. Das in einer Hochsprache geschriebene einzelne Statement wird (nach Optimierungen) in Maschinensprache übersetzt, sieht in der Struktur dem Quellcode relativ ähnlich.
5. Deklarativ.
   • Das ist ein ganz anderes Geschäft.
   • Dazu gehört eigentlich immer ein sogenannter Solver, oder sowas Ähnliches (in manchen Bereichen Engine genannt). Er nimmt die Problembeschreibung entgegen und löst dann die damit verbundene Aufgabe. Dahinter können umfangreiche mathematische Verfahren stecken. Was dann als ausführbarer Maschinencode passiert, hat mit den Statements des Quellcode rein gar nichts mehr zu tun. Der wesentliche Teil des Maschinencode stammt aus den intern eingebauten Problemlösungstechniken; der Quellcode liefert eher Parameter und Daten für die Problemlösungsfunktion. >> Ja, sowas Ähnliches in 'artikelfähigem' Text wäre m.E. passend.
   • Man könnte sagen: Bei Deklarativem Paradigma wird vom Menschen das (inverse?) Problem beschrieben; der Solver macht eine Invertierung, um sich den Lösungsalgorithmus quasi selbst zu schreiben. Hingegen wird beim Imperativen Paradigma der Lösungsalgorithmus direkt vom Programmierer hingeschrieben. >> Das ist schon bei Programmierparadigma so festgelegt. Was ist evtl. beim Compilieren anders?
   • Es mag zwar eine kompilierende (syntaktische) Umformung eines deklarativen Quelltextes geben, etwa im Sinne einer Fehlerkontrolle und kompakteres Format, aber ein vergleichbares Kompilieren dürfte eher selten sein.

Zwecks Verständlichkeit jetzt etwas grob runtergebrochen und freihändig aus dem Ärmel geschüttelt; schönes Wochenende --PerfektesChaos 15:16, 11. Aug. 2012 (CEST)

Hallo 'Perfektes Chaos', danke für die Anmerkungen. Die ToDo's sind (aus meiner Sicht) nur als Beitrag zu einer 'Top-Down-Vorgehensweise' gedacht, d.h. die einzelnen Punkte sind lediglich 'Merker', zu denen sich letztlich im Text des Artikels Aussagen, möglichst mit Beleg finden sollten. Solche Texte könnten/sollten im Abschnitt #Entwurfstexte (jeweils mit passender Überschrift oder Verweis zum Artikelabschnitt) eingestellt und ggf. noch diskutiert werden, und dann final in den Artikeltest wandern. Deine Inhalte können sicher dazu beitragen, aber du siehst sie in dieser Form wahrscheinlich auch nicht als Artikeltext - oder? Natürlich darf man auch über diese ToDo's diskutieren. Deshalb habe einige Anmerkungen meinerseits oben in deinen Texten eingefügt. Lass uns aber erst die ToDo-Liste fertigmachen und dann entsprechende Textpassagen formulieren.

Schönen Sonntag wünscht: --VÖRBY (Diskussion) 18:21, 11. Aug. 2012 (CEST)

Zurzeit ist es erstmal nur ein internes Herausarbeiten der Sachverhalte. Dass daraus ein für die Außenwelt geeigneter Text wird, ergibt sich erst nach interner Klärung.

• Die momentane Hauptschwierigkeit liegt offenbar in der Abgrenzung Interpretierer ./. Compiler; ich probiere es daher noch einmal:
  • Beim Interpretierer sind alle ausführbaren Aktivitäten schon Monate und Jahre vorher als Maschinencode der Zielplattform eingebaut worden und schlummern in fertigem Zustand. Wenn ein Anwender mit seinen interaktiven oder geskripteten Statements kommt, dann sind diese Zeichenketten nur Daten. Die geeigneten vorbereiteten Aktivitäten werden mit den aktuellen Parameterwerten befüllt und vom Interpreter als eigenständigem, ausführbarem Programm exekutiert. Irgendein neuer Code entsteht dabei nicht, und üblicherweise bleibt von der Aktivität des Anwenders auch nix über, zumindest nicht in Form von übersetzten Befehlscode-Dateien.
  • Der Compiler übersetzt Statements (die identisch mit den soeben in den Interpretierer gefüllten sein können) von einem Sprachniveau in ein anderes, hier ein maschinengeeigneteres. Das Resultat wird als Datei zur weiteren Verwendung abgelegt. Dabei muss die Plattform der Sprachniveaus noch nicht einmal mit der aktuellen Plattform übereinstimmen. Ausgeführt wird nichts.
  • Klipp und klar: Ein Interpreter ist kein Compiler. Beide machen etwas völlig anderes, bloß möglicherweise mit dem identischen Quellcode (selten).
• Objektorientierung verändert nichts Grundsätzliches an den Mechanismen von Interpretern und Compilern.
• Prinzipiell darf man bei deklarativen Sprachen von Compiler reden. Wenn ich die mir bekannten Fälle durchgehe, verwendet man aber seltener in diesem Zusammenhang die Vokabel „Kompilieren“. Bei Haskell als nicht-imperativ aber funktional noch am ehesten; auch LISP lässt sich funktional einsetzen, aber auch klassisch prozedural und wird kompiliert, wobei der Anwender separat die Lösungsprozedur schreiben müsste. Bei Prolog wird das konkrete Problem von einem Interpreter verarbeitet.

Hoffentlich wieder einen Schritt weiter --PerfektesChaos 20:24, 12. Aug. 2012 (CEST)

Interpreter vs deklarativer Code

(Fortsetzung vom vorherigen Abschnitt)
Danke für deine Anmerkungen. Dass das Interpretieren etwas ganz anderes ist als das Übersetzen, wird jetzt erst richtig sichtbar; im bisherigen Text ist z.B. von 'Befehl-für-Befehl' übersetzen oder von 'en-bloc' die Rede. Dagegen werden, wie du schreibst, ganze, schon vorhandene Programme ausgeführt - die die Sprachkonstrukte lediglich als Parameter verwenden. Es wird also wirklich nichts (Neues) erzeugt! Allerdings glaube ich, dass dieser Unterschied nicht zufällig von 'Kompilieren vs. Interpretieren' abhängig ist, sondern dass diese Art von Interpretieren einfach bei deklarativem Code praktiziert wird - und auch gar nicht anders möglich ist. Ich werde dazu hier noch ein Beispiel einfügen. Insgesamt sind wir mit diesem Punkt wirklich 'einen Schritt weiter'. --VÖRBY (Diskussion) 08:47, 13. Aug. 2012 (CEST)

Hier ergänze ich um Beispiele (Bezug: MS Access):

Bei deklarativer Programmierung wird das WAS definiert. Da ein Computer aber nur einen Befehl nach dem anderen abarbeiten kann, braucht es eine Zwischenkomponente, die diese Art von WIE erzeugt.

• Beispiel Reportgenerator: Die Reportspezifikation definiert lediglich, wie der Report aussehen soll, seine Datengrundlagen etc. In der Laufzeitumgebung gibt es einen 'Eventmanager', der ein 'richtiges Programm' ist, das über das Betriebsswystem vom Prozessor ausgeführt wird, das zunächst mit dem einzelnen Report nichts zu tun hat, aber 'weiß', welcher Report ausgeführt werden soll. Bei Eintritt bestimmter Ereignisse (die es feststellt) bezieht sich dieses Programm auf die deklarativen Festlegungen und füllt (zum Beispiel) ein Datenfeld im Report (bzw. alle dort vorgesehenen Datenfelder) mit bestimmten Daten in bestimmten Formaten. Evtl. vorhandener VBA-Code (für ein bestimmtes Objekt/Ereignis) könnte dagegen Befehl für Befehl compiliert/interpretiert werden; das ist aber dann imperativer Code!
• Beispiel SQL: Ein mächtiges Datenbankprogramm der Laufzeitumgebung kann alle in SQL möglichen Funktionen ausführen. Es benutzt dazu die Angaben aus dem SQL-Code in seinen eigenen Befehlen als Quelle. 'Übersetzen' in Maschinenbefehle kann man SQL-Code nicht.

In beiden Fällen wird der deklarative Code nicht 'übersetzt' sondern nur 'berücksichtigt' (also wie normale 'Daten' als Parameter verarbeitet). Das wäre also im Wortsinn 'interpretierter Code', aber keine 'Übersetzung' des Quellcodes in Maschinenbefehle, der Interpreter hier also kein 'Compiler'.

Fazit:

• Es gibt wohl mehrere Arten von 'Interpretern': Befehl-für-Befehl umwandeln; Maschinencode en-bloc erzeugen (praktisch identisch mit Compilieren); Code lediglich interpretativ verwenden. Zumindest Letzteres ('Ausführung über Laufzeitumgebungen') sollte anders genannt und/oder aus der Definition von 'Compiler' abgegrenzt werden.
• Deklarativer Code wird gänzlich anders umgesetzt - als z.B. imperativer.

Somit sollten wir die Lemma-Texte zu diesem ToDo entsprechend als Entwurf vorbereiten können. Magst du oder soll ich? Grüße von --VÖRBY (Diskussion) 11:26, 13. Aug. 2012 (CEST), ergänzt: --VÖRBY (Diskussion) 18:44, 13. Aug. 2012 (CEST)

Komplex-zu-Einfach

Ich würde gerne anführen, dass Compiler praktisch immer aus einer komplexen (Hoch-)Sprache in eine einfachere Sprache übersetzen. Und wenn nicht, dann werden in der Zeilsprache zumindest gleich-einfache oder einfachere Konstrukte verwendet als in der Quellsprache. Hat jemand dazu eine Quelle?

In der Optimierung wird (selten!) eine Komplexitäts-Erhöhung vorgenommen (z.B. Macro-OP-Fusion im Prozessor, oder Compiler#Einsparung von Maschinenbefehlen).

Dass in der Zielsprache tatsächlich komplexere Konstrukte verwendet werden, als in der Quellsprache, kenn' ich allenfalls aus (nichtmenschlichen) Übersetzern menschlicher Sprachen.

--arilou (Diskussion) 12:06, 13. Aug. 2012 (CEST)

Oder: Ein Decompiler kann das, wenn zuvor bekannt ist, dass die ursprüngliche Quellsprache dieselbe war, wie die Zielsprache des Decompilers, und er das entsprechende Background-Wissen hat. Keine Ahnung, was ein Decompiler macht, wenn man versucht, ein Maschinenprogramm, das mal Pascal war, zu C-Code zu decompilieren... --arilou (Diskussion)

Wird der erzeugte Code für den Quellbefehl 'A = B / (C(Index) / 100)' (mit evtl. erforderlichen Formatkonvertierungen und Kommastellen-Adjustierungen) tatsächlich 'einfacher' sein als dieser 'komplexe Ausdruck'? Man müsste also 'komplex' und 'einfach' irgendwie anders benennen.--VÖRBY (Diskussion) 18:44, 13. Aug. 2012 (CEST)

Hm, es gibt gegenläufige Bedeutungsfelder:

1. Schwierig für den Menschen zu verstehen (=komplex) vs. Einfach für den Menschen zu verstehen (=einfach). Dabei müsste eine Hochsprache immer als "einfach" gelten, und Assembler als "komplex/schwierig".
2. Operationen mit viel Hintergrundwissen/-aktivitäten und viel Flexibilität (=komplex) vs. Befehle mit einfacher Bedeutung und fester Schnittstelle (=einfach). Dabei ist die Hochsprache dann "komplex", da ihre Operationen alle möglichen Checks, Wandlungen usw. im Hintergrund durchführen, wohingegen eine Assembler-Anweisung eine einfache, feste Bedeutung haben.

Daher stimm' ich zu, dass die beiden Begriffe "komplex" und "einfach" problematisch sind.

--arilou (Diskussion) 15:00, 14. Aug. 2012 (CEST)

Aktionismus von Benutzer 0x

Hallo Leute, wir strampeln uns hier einen ab, um den Artikel zu verbessern. Dies alles interessiert 0x überhaupt nicht, sondern er ändert einfach nach seiner Meinung und verschiebt bereits diskutierte Textteile. Ich habe in seiner Diskussionsseite meine Kritik formuliert und überlasse es euch, daraus eure Schlüsse zu ziehen. Vielen Dank jedenfalls für die ernsthafte Mitdiskussion hier. Vorläufig steige ich aus diesem Lemma aus, so lohnt sich der Aufwand nicht. --VÖRBY (Diskussion) 11:22, 15. Aug. 2012 (CEST)

Tut mir leid, wenn ich zu offensiv war. Habe auf meiner Disk auch geantwortet. Ich halte die Reaktion artikelmäßig aber für etwas übertrieben. Siehe meine Disk. ʘχ (Diskussion) 13:56, 15. Aug. 2012 (CEST)

Entwurfstexte

(sprachlich-stilistische Verbesserungen bitte ggf. direkt einstellen, inhaltliche Aspekte bitte unten diskutieren))

==Textfragmente zur Einleitung==

Entwicklungen in der Computertechnik wirkten auch auf die Compilierungsverfahren:
Die rasante Entwicklung in der Computertechnik, während der Verbesserungen in der Hardware neue Möglichkeiten in der Software erlaubten (die wiederum nach 'stärkerer' Hardware verlangte), wirkte auch auf die Softwaretechnik und die Programmiersprachen – die wiederum die Verfahren der Codekonvertierung beeinflussten. So sind bis heute ~hochgradig unterschiedliche Verfahren und auch Begriffe für den Sachverhalt 'Compilieren' im Einsatz. Gemeinsam ist all diesen Techniken, dass der vom Programmierer erzeugte Quelltext letztlich vom Rechner ausgeführt werden kann.

Komplex-zu_Einfach: (Lt. Anregung von Arilou hier)
Hier noch Textvorschlag / Textfragment einstellen

=== Teilfunktionen bei der Übersetzung ===
(Texte waren entfernt worden. Sie sind aber, besonders für Laien, relevant!)

Ohne auf Details zu bestimmten Programmiersprachen/Compilern einzugehen, wird beim Übersetzen des Quellcodes in Maschinencode im Wesentlichen folgende Funktionalität ausgeführt:

• Prüfung des Quellcodes: Die Einhaltung der Syntaxregeln der jeweiligen Sprache, die Verwendung gültiger Schlüsselwörter und gültiger Bezeichner wird überprüft. Festgestellte Fehler werden protokolliert, ein (gültiger) Zielcode wird nicht erzeugt.
• Reservieren von Speicherplatz: Alle definierten Datenbereiche werden so angelegt wie sie im späteren internen Speicher liegen werden. Der Übersetzer 'kennt' für jedes Datenfeld die Position, die Länge und das Datenformat und verwendet diese Informationen beim Erzeugen der Befehle, die die einzelnen Felder ansprechen.
• Belegen der Inhalte von Konstanten
• Umwandeln der Befehle des Quellcodes in adäquate Befehle der Maschinensprache:
  • Aus den sprachspezifischen Befehlscodes wird Maschinenbefehlscode
  • Aus logischen Feldnamen in diesen Befehlen werden numerische Adress- und Längenangaben.
  • In der Regel kann der Quelltext-Befehl nicht 1:1 umgewandelt werden, sondern erfordert in der Zielsprache mehrere Befehle - z. B. wenn Formatkonvertierung erforderlich ist, wenn Array-Adressen berechnet werden müssen, zur Zuweisung von Registeradressen etc.
  • Für logische Ausdrücke im Quellcode (wie Klammern, Und/Oder, arithmetische Regeln (z. B. 'Punkt vor Strich'), Wenn/Dann/Sonst; auch mehrfach geschachtelt) werden alle erforderlichen Befehle erzeugt; für die korrekte Reihenfolge der Verarbeitung (z. B. bei alternativ auszuführenden Verarbeitungszweigen) werden entsprechende Sprungbefehle eingefügt.
• Für sprachspezifische oder funktionale, zur Ausführung erforderliche Subroutinen/Module werden Aufrufbefehle eingefügt – inkl. der Übergabe der formalen Parameter.

== Übersetzungsszenarien == vormals: >Zeitpunkt der Übersetzung > Ablaufprinzipien
(Texte waren aus dem Lemma entfernt worden; hier Wiedereinstellung nach Anpassung)

Bezüglich des Vorgangs der Übersetzung von Quellcode in Maschinencode – der zur Ausführung von Programmen grundsätzlich erforderlich ist – lassen sich die folgenden Grundszenarien unterscheiden:

• Ahead-of-time-Kompilierung: Die Übersetzung findet einmalig mit dem Programmtext als Ganzem statt, der erzeugte Code kann anschließend beliebig oft ausgeführt werden. Der Compiler liest als Dateneingabe den Programm-Quellcode und liefert als Datenausgabe den Maschinencode (z. B. Objectcode, EXE-Datei, „executable“) oder einen Zwischencode. Die Kompilierung findet in der Regel innerhalb der Prozesse des Release Managements statt.
• Just-in-time-Kompilierung: Der Programmtext wird direkt vor jedem Programmlauf neu übersetzt; die Erzeugung von Maschinencode kann 'Befehl-für-Befehl' erfolgen (mit sofort anschließender Ausführung der erzeugten Befehle) oder ebenfalls eine Komplett-Kompilierung sein. Vorteil: Die Compilierung kann bei Bedarf unterschiedliche Zielarchitekturen beliefern.
• Interpretation zur Laufzeit: Z. B. mit JVM, .NET CLR oder MS Access) wird der Programmcode während der Ausführung lediglich interpretiert. Man spricht von einer interpretierten Sprache, die Quellanweisungen werden nicht wirklich in eine andere Zielsprache übersetzt, sondern bei der Ausführung als Parameter berücksichtigt.

Daneben werden verschiedene Varianten dieser Grundkonzepte praktiziert:

• Zum Teil erzeugen Compiler einen noch nicht ausführbaren Programmcode, der von nachfolgenden Systemprogrammen zu ausführbarem Maschinencode umgeformt wird. Hier sind die Konzepte „plattformunabhängiger Zwischencode“ (z. B. im Rahmen der Software-Verteilung) und „plattformgebundener Objectcode“ (wird zusammen mit weiteren Modulen zu ausführbarem Code, z. T. Lademodul genannt, zusammengebunden) zu unterscheiden.
• Mit Precompilern können spezielle, in der Programmiersprache selbst nicht vorgesehene Syntax-Konstrukte (zum Beispiel Entscheidungstabellen) bearbeitet und, vor-übersetzt in die gewählte Programmiersprache, im Quellcode eingefügt werden.

Zur Steuerung des Übersetzens kann der Quelltext neben den Anweisungen der Programmiersprache zusätzliche spezielle Compiler-Anweisungen enthalten. Komplexe Übersetzungsvorgänge werden bei Anwendung bestimmter Programmiersprachen / Entwicklungsumgebungen durch einen Projekterstellungsprozess und die darin gesetzten Parameter gesteuert.

== Ablaufbeispiele: ==
Zum besseren Verständnis der möglichst allgemeingültig formulierten Beschreibung unter Übersetzungsszenarien werden nachfolgend konkrete Beispiele für den Ablauf der Übersetzung bei Einsatz bestimmter Entwicklungstechniken beschrieben.

Ablaufbeispiel IBM-Großrechner / 3GL-Sprache

===Szenario IBM-Großrechner mit 3GL===
Der Compiler übersetzt den per Texteditor erzeugten, optional von Precompilern ergänzten Quellcode für genau ein 'Programm' (PGM X) und erzeugt dabei prozessorspezifischen Objektcode. Soll das Programm direkt vom Betriebssystem aufrufbar sein, so wird dieser Code mit dem 'Linkage Editor' um sprachspezifische Systemmodule ergänzt und der Objektcode aufgerufener Unterprogramme hinzugebunden. Ergebnis ist ein ausführbares Lademodul für das 'Programm X'. Für nicht getrennt aufrubare Unterprogramme wird nur der Objektcode erzeugt - der nur beim Linken der sie aufrufenden Programme verwendet wird.
Im Quellcode können Befehle enthalten sein, die nicht zur Programmiersprache selbst gehören (z. B. SQL-Code) und aus denen eigener Objektcode erzeugt wird. Diese Befehle werden im Quellcode meist 'auskommentiert' und durch den Aufruf des adäquaten Unterprogramms ergänzt, das beim Linken und/oder bei der Ausführung aufgerufen wird.

Entwicklung und Ausführung mit MS Acess

===Szenario MS Access (deklarativ)===
Mit MS Access werden Anwendungen zu großen Teilen deklarativ entwickelt, nur individuell mit VBA implementiertre Funktionalität ist imperativer Code. Alle Spezifikationen werden von MS Access gemeinsam in einer Systemdatei (.MDB) verwaltet, die auch zur Ausführung benutzt wird. Die Anwendung wird von der Laufzeitumgebung objekt- und ereignisorientiert ausgeführt, wobei in der Verarbeitung der einzelnen Ereignisse die hierzu spezifizierten Festlegungen berücksichtigt und umgesetzt werden. Bei diesem Szenario findet (außer für VBA-Code, falls vorhanden) keine Codekonvertierung (zu Maschinencode) statt.

Diskussionen zu Entwurfstexten

Was sagt uns dieses Access-Beispiel bitte über Compiler aus? Ich sehe überhaupt nicht, was jetzt damit klar gemacht werden soll? --Chricho ¹ ² ³ 02:36, 14. Aug. 2012 (CEST)

Als Klarstellung, dass es "vom Quellcode zur Ausführung" auch ein Szenario gibt, das nichts mit Compiler und Befehls-Interpreter zu tun hat - wie im letzten Satz auch ausgedrückt wird. Gruß von --VÖRBY (Diskussion) 20:45, 14. Aug. 2012 (CEST)

Was macht denn die sogenannt „Laufzeitumgebung MS Access“ anderes als interpretieren (oder evtl. kompilieren)? --Chricho ¹ ² ³ 21:30, 14. Aug. 2012 (CEST)

"C-Präprozessor ist ein Compiler"

// kopiert aus vorigen Abschnitten:

"So ein C-Präprozessor ist zweifelsohne ein Compiler für eine gewisse Sprache," von Benutzer:Chricho

Hm, ein Präprozessor ist imo kein Compiler. Präprozessor-Anweisungen werden nicht "übersetzt", sondern ausgeführt, indem die entsprechenden Quellcode-Umbauten durchgeführt werden. Insofern kommt ein Präprozessor eher einem Interpreter gleich, der den Input (C-Quellcode) gemäß eingebetteter Anweisungen umbaut und als Output nun reinen C-Code weitergibt. --arilou (Diskussion) 11:31, 7. Aug. 2012 (CEST)

[...] Ein Präprozessor ist definitiv ein Compiler, die Sprache, die der übersetzt, ist aber eben so angelegt, dass das Quellprogramm den Kompilierungsvorgang recht direkt steuert, das ist bei zahlreichen Sprachen mit Metaprogrammierungsfähigkeiten nicht anders. [... <Compiler vs. Translator> ...]Ein C-Präprozessor wäre aber zweifelsohne in beiden Fällen dabei, denn er ist nunmal kein Textverarbeitungstool sondern dient der Überführung in Richtung ausführbarer Code. Wie auch immer, wie ein Präprozessor heißt, ist gar nicht mal so wichtig: [...] von Benutzer:Chricho

[...] Dann sagst du, ein C-Präprozessor gehöre 'zweifelsohne' dazu - und schreibst, dieser erzeuge Code 'in Richtung' ausführbarer Code. Das ist ein erheblicher Unterschied. [...] von VÖRBY

Man kann den C-Präprozessor auch alleine betreiben, ohne den Compiler dahinter, z.B. um in LaTeX-Dateien Makros zu ersetzen, und einzelne Dateien ineinader zu inkludieren.

Der (C-)Präprozessor ist natürlich kein Compiler, seine Anweisungen werden ja nicht übersetzt. Und bevor Chricho jetzt das Gegenteil behauptet, darf er mir mal erklären, in wechen C-Code bitteschön ein

#include xxx.c

ersetzt wird? In

FILE* f=fopen("xxx.c",r); // [...]

oder in was bitteschön? Und was wird aus

#define a 17

? Vielleicht der C-Code

const int a=17;

? Mitnichten. Die Präprozessor-Anweisungen werden ausgeführt wie bei einem Interpreter, es werden entsprechende Aktionen durchgeführt. Danach sind sie WEG und keine übersetzte "semantische Entsprechung" verbleibt im Output. --arilou (Diskussion) 14:02, 7. Aug. 2012 (CEST)

Kann man so benutzen, dafür ist er aber nicht gedacht, es geht um die Intention. Ich kann auch einen C-Compiler als Entropiequelle benutzen, es bleibt ein Compiler. In welchen Code wird denn import blub; in einem Java-Programm übersetzt? Und dass das Kompilieren eine Ausführung von Makros beinhaltet ist keine Besonderheit, sondern elementar für Metaprogrammierung. Ich habe aber auch keine Lust darüber zu diskutieren, da das völlig nebensächlich ist, insbesondere für die Einleitung, die ist nämlich nicht für Negativlisten von irgendwelchen Sachen, die man in bestimmten Kontexten nicht mit dem Wort Compiler meint, gedacht, sondern für eine Definition. Und da müsste man sich erst einmal grundsätzlicher verständigen. Was ist z. B. mit einem TeX-Compiler? --Chricho ¹ ² ³ 18:03, 7. Aug. 2012 (CEST)

Oder anders ausgedrückt: Muss das Ziel eine Ausführung sein, oder soll es allgemein um die Übersetzung in ein Äquivalent in einer anderen Sprache gehen? --Chricho ¹ ² ³ 18:07, 7. Aug. 2012 (CEST)

Ja Leute, wir erfahren hier selbst, wie uneindeutig die Texte zu unserem Lemma sind. Wie so oft dürfte es auch hier wahrscheinlich Definitionen im engeren Sinn und solche in erweitertem Sinn geben. Als Compiler im erweiterten Sinn kann m.E. ein Precompiler (und wohl auch für mehrere andere 'Hilfsmittel') schon gelten, schließlich 'übersetzen' solche Werkzeuge ja ihre Anweisungen in einen anderen Code. Aber wir dürfen auch keine Theorien erfinden, sondern sollten uns auf Belege beziehen.

Unabhängig davon ist das Beschreiben dieses Lemmas wegen der vielen verwendeten Technologien mit jeweils optionalen Komponenten eine knifflige Aufgabe. Ich halte deshalb die hier diskutierte Frage zwar für interessant, aber i.S. der Zielsetzung (Klarheit über alle Varianten?!) nur für einen 'kleinen Zipfel des Problems'. Es lohnt sich alsi nicht darüber weiter zu 'diskutieren'.

Ein evtl. klarerer Ansatz könnte sein, relevante Szenarien ganz konkret zu beschreiben, ohne neutralisierende Begriffe und Relativierungen wie "z.B." anwenden zu müssen. Das könnten dann zwar einige Szenarien werden, die könnten dann aber klar zeigen was als Compiler und deren Umfeld (in/Out) gilt und was nicht. --VÖRBY (Diskussion) 19:38, 7. Aug. 2012 (CEST)

Begrifflicher Nebel nach einem halben Jahrhundert

1. Die Vokabel „Compiler“ hat 60 Jahre IT-Geschichte auf dem Buckel. Das ist ähnlich wie bei Textverarbeitung, DTP, CAD  – in jedem Jahrzehnt verstand man unter diesen Begriffen etwas anderes.
2. Die geläufigste Bedeutung ist zweifelsfrei die Erzeugung von Maschinencode (oder zumindest Assembler).
3. Auch die Gebilde zur Erzeugung von Zwischencode heißen aber Compiler.
   • Der früheste Vertreter schon in den 1960er Jahren war LISP, durch das damals auch der Begriff Bytecode geprägt wurde.
   • Die Quellcode-Übersetzer in Java und C# heißen ebenfalls „Compiler“.
4. Jede Marketing-Abteilung verkauft ihr Produkt unter dem hochtechnisch klingenden Namen „Compiler“, auch wenn nur ein Dutzend RegExp dahintersteckt und eine banale Textersetzung erfolgt.
   • Auch einen schlichten Minifier kann man als Precompiler verkaufen; man kann Kommentare und Whitespace rausnehmen, Präprozessor-Direktiven ausführen und konstante Ausdrücke vorab berechnen oder Syntaxoptimierung vornehmen.
5. Nach mehr als einem halben Jahrhundert gibt es etliche Konzeptionen und Architekturen, Zwitter und Zwischenstadien, Mischformen und Übergangsstadien wie auch Doppelnutzungen. In das klassische Schema lassen sich nicht alle zwängen.
6. In einer heute aufgefallenen Redundanzdisku hatte 2004 mal jemand einen Artikel Übersetzer (Informatik) vorgeschlagen.
   • Das wäre gar nicht so ungeschickt, um in einer Übersicht die Gemeinsamkeit aller hier fallenden Begriffe darzustellen: Von einem tendenziell eher menschenlesbaren Quelltext zur nächsten Stufe eines maschinengeeigneteren Codes.
   • Das kann über viele Zwischenstufen erfolgen:

     Quelltext → Präprozessor → Compiler → Assembler → Prozessorcode

     Quelltext → Compiler → Zwischencode → JIT-Compiler → Assembler → Prozessorcode

   • Da kann man dann die Varianten von Compiler, Interpreter (auch kein fundamentaler Unterschied), Textersetzung usw. sauber aufdröseln.
7. Linker lassen sich hingegen deutlich unterscheiden; sie lösen symbolische und relative Referenzen auf in weniger relative (bis absolute). Und ein wenig C&P und Bibliotheksindex. Mehr eigentlich nicht.

Liebe Grüße --PerfektesChaos 20:07, 7. Aug. 2012 (CEST)

Ich stimme darin zu, dass es nach mind. 60 Jahren IT-Sprachgebrauch 'ne Menge Wandel und Vielfalt in der Bedeutung von "Compiler" gab, und auch heute vieles darunter fällt.

Worin ich nicht zustimme, ist "TF -Artikel-Erstellen", auch wenn's "nicht ungeschickt [wäre], um in einer Übersicht die Gemeinsamkeit aller hier fallenden Begriffe darzustellen". Vielleicht ginge eine Aufsplittung ähnlich

• "Compiler (zu Maschinencode)"
• "Compiler (Sprache-zu-Sprache)"
• "Compiler (...)"

aber mir fallen eigentlich keine guten Klammer-Inhalte ein.

Im Moment seh' ich immernoch keine passable andere Möglichkeit, als das Problem hier, in nur einem Artikel, zu lösen (zu versuchen).

--arilou (Diskussion) 09:44, 8. Aug. 2012 (CEST)

Aussage zu „interpretierte Sprache“, und überhaupt.

Vorsicht mit der Aussage

spricht man von einer interpretierten Sprache. Das Programm wird in einer Laufzeitumgebung (z. B. JVM oder .NET CLR) interpretiert.

Das hat zwei Macken:

1. Der Begriff „interpretierte Sprache“ ist ein eigen Ding, dazu gleich mehr.
2. In der Laufzeitumgebung wie JVM oder in .NET wird nix interpretiert.
   • Hier wird ein komplett als Zwischencode vorliegendes Programm in die plattformabhängige (maschinennahe) Sprache vollständig kompiliert und dann ausgeführt.

Das mit der „interpretierten Sprache“ wird oft palavert; es gibt aber weder interpretierte noch kompilierte Sprachen als solche. Vielmehr gibt dies unterschiedliche Verarbeitungsabläufe wieder, die mit ein und demselben Quellcode derselben Sprache betrieben werden können.

• Als „Interpretation“ bezeichnet man die Arbeitsweise, dass ein einzelnes Statement einer Programmiersprache (unter Berücksichtigung von Umgebungsbedingungen, etwa Variablen) vom Quelltext in eine ausführbare Form übersetzt und dann sofort ausgeführt wird.
  • Insbesondere interaktiv kann man sich das Resultat dieser Ausführung anschauen und dann spontan entscheiden, was man als nächstes Statement haben möchte. Bekannt ist diese Arbeitsweise von Betriebssystem-Shells („Kommandozeilen-Interpreter“), aber auch Roboter (CNC) oder Malprogramme lassen sich so steuern, wie auch ein SQL-Dialog.
  • Jedoch kann auch eine „kompilierte Sprache“ einzelschrittweise ausgeführt werden, etwa in einem interaktiven Debugger. Dann kann man die geänderten Variablen inspizieren. Hier lässt sich aber meist nicht während der Abarbeitung die nächste Zeile des Quellcodes verändern (ohne den Debugger zu beenden).
• Wenn man einen Stapel an zu interpretierenden Anweisungen zusammenfasst und mit Parametern versieht, bekommt man – Stapelverarbeitung. Jetzt auf einmal kann man auch „Skriptsprache“ dazu sagen; auch so ein schwammiger Begriff. Bei einer Skriptsprache kommen Kontrollstrukturen hinzu, die bei einer interaktiv interpretierten Arbeitsweise noch keinen Sinn haben.
• Niemand kann mich hindern, den Stapel an zu interpretierenden Anweisungen vorher zu übersetzen und nicht die gesammelten Einzelstatements des Skriptes zeilenweise zu übersetzen, sondern im Vorfeld den ganzen Block. Dann wäre es aber eine „kompilierte Sprache“.
• Die ganze Unterscheidung in diese Sprachen ist Humbug. PHP hat als „interpretierte Sprache“ angefangen und wird heute kompiliert; genauso diverse angebliche „Skriptsprachen“ (perl, py). Auch BASIC wurde zu Zeiten des Wohnzimmerfernsehers interpretiert; VisualBasic kompiliert. So what?
  • Nach typischen Anwendungsgebieten werden die Sprachen pauschal in Schubladen gesteckt, ohne dass diese eine Begründung in den Eigenschaften der Sprache selbst hätte.

Was das jetzt mit deklarativer Programmierung zu tun haben soll, erschließt sich mir rein gar nicht.

Liebe Grüße --PerfektesChaos 16:54, 10. Aug. 2012 (CEST)

Ja, Interpretiertheit ist in der Tat keine Spracheigenschaft. Wo steht etwas von Deklarativem? Im Beiträg von VÖRBY? Ja sehe ich jetzt auch nicht, worauf er damit hinaus wollte. --Chricho ¹ ² ³ 17:02, 10. Aug. 2012 (CEST)

Ich weiß auch nicht, warum sich diese Formulierungen so hartnäckig halten, aber vielleicht deshalb, weil das jeder Privatmensch in seinem Online-Tutorial zu seiner Lieblingsprogrammiersprache nicht zu erwähnen vergisst, zu denen der Zugang einfacher als zu einem Buch ist, und schließlich auch Leute vom Fach das übernehmen, um die Lücken im Text zu füllen. Ein Paradebeispiel für die Unzuverlässigkeit des Webs als Quelle. [1] [2] [3]

Vielleicht hilft ein Vergleich mit natürlichen Sprachen. "Interpreter" ist englisch für "Dolmetscher". Und dass man Englisch, Deutsch oder auch isiZulu nur am Stück übersetzen, aber nicht dolmetschen könne, oder umgekehrt, würde so leicht keiner bereit sein zu glauben und nachzuplappern. --Zahnradzacken (Diskussion) 17:35, 10. Aug. 2012 (CEST)

Ja, Leute, das mit imperativ vs. deklarativ war 'auf meinem Mist' gewachsen und kommt von meiner Erfahrung, dass neuere Sprachen, die häufig in Laufzeitumgebungen ausgeführt werden (und zu großen Teilen deklarativ sind), in die Interpreterschublade gehören sollten. Da das auch ohne Beleg ist, nehme ich die beiden Aussagen wieder raus.

Unabhängig davon meine ich aber, dass diese Sprachekategorien (-Paradigmen) doch auch mehr oder weniger starke Unterschiede in den Übersetzungsmechanismen haben müssten - und also im Artikel erwähnt werden sollten. Wer könnte dazu mit Text beitragen?

Ansonsten sehe ich nach wie vor und immer mehr die Notwendigkeit zur Qualitätsverbesserung hier im Lemma. Siehe #ToDo's. Grüße von --VÖRBY (Diskussion) 19:36, 10. Aug. 2012 (CEST)

So klappt das nicht

Zu den "Entwurfstexten"

Ich sehe bezüglich der oben diskutierten "Entwurfstexte" folgende Probleme:

• Der Stil ist journalistisch, nicht enzyklopädisch.
• Der Inhalt orientiert sich nicht an den fachlichen Begriffen, sondern an einer bloßen, mehr oder weniger laienhaften Phänomenologie, das heißt der Frage: Wie nimmt man als Außenstehender die Tätigkeit eines Compilers wahr? Ein Artikel aus dem Bereich Informatik hat sich jedoch Regeln zu unterwerfen. Er muss sich an den Standards der wissenschaftlichen Disziplin messen. Das heißt, er muss insbesondere:

1. sich gemäß der in der Disziplin üblichen Standards strukturieren,
2. sein Lemma diesen Standards folgend definieren und erklären,
3. und mit entsprechender begrifflicher Präzision vorgehen.

Solange die Standards der Disziplin grob verletzt werden, sehe ich keine Diskussionsgrundlage, denn die Grundlagen der Informatik diskutiert man nicht, sondern liest sie nach (oder besucht Vorlesungen, wie auch immer). (Ich hoffe, es fordert mich jetzt niemand auf, diese "Standards" oder Grundlagen zu definieren, denn die kann man recherchieren, und diese Verantwortung hat auch jeder Autor für sich selbst.)

Theoriefindung

Die Diskussion ist mir insgesamt zu stark in ein "Gespräch im Bierzelt" und WP:TF abgeglitten. Anstatt sich an den üblichen Begriffen und Definitionen zu orientieren und diese im Artikel darzustellen, wird philosophisch darüber debattiert, welche Begriffsbestimmungen und Klassifikationen man vornehmen könnte. (Siehe etwa "Begrifflicher Nebel", manche Fragen bei den "ToDos", Diskussionen dazu, "C-Präprozessor".) Davon haben wir aber nichts, denn die dabei entstehenden Theorien können wir ohnehin nicht in den Artikel einbauen. @VÖRBY: Das ist dir hier ja auch aufgefallen, denn du schreibst: Aber wir dürfen auch keine Theorien erfinden, sondern sollten uns auf Belege beziehen.

Wenn wir uns über einen Begriff uneins sind, dann müssen wir den eben recherchieren. Aber hier rumspekulieren nach dem Motto: "Hm, was hat es wohl mit dem Begriff auf sich... könnte man nicht... ist es nicht so, dass..." -- das hat für den Artikel keinen Nutzen.

Unterm Strich: Was ich hier mache, ist kein Aktionismus (@VÖRBY). Das sollte auch aus meinen Änderungen hervorgehen. Ich bin bei der WP, nicht um zu stören, sondern um mitzuarbeiten; aber aus den genannten Gründen kann ich man an dieser Diskussion in dieser Form nicht beteiligen. Lasst uns am Artikel arbeiten, und zwar unter Wahrung enzyklopädischer und informatischer Standards und ohne eigene Theorien über die auftretenden Begriffe aufzustellen. ʘχ (Diskussion) 14:39, 16. Aug. 2012 (CEST)