Frank Schönmann: Was sind Programmiersprachen?

hi!

Wir haben gerade ein schwerwiegendes Problem im Chat: Was sind Programmiersprachen bzw. ist JavaScript eine Programmiersprache?

Meine vorgeschlagene Definition von Prorgrammiersprache war folgende:
Eine Programmiersprache ist eine Kunstsprache, die dem Anwender hilft, dem Computer Algorithmen in einer dem Computer verständlichen Form zu vermitteln.

Leider ist Sebastian nicht ganz meiner Meinung. Er findet, eine Programmiersprache definiert sich einzig und alleine aus ihrer Weiterverarbeitung: es handelt sich also nur um eine Programmiersprache, wenn sie vor der Ausführung kompiliert wird, so wie C, Pascal, Perl und so weiter. Da JavaScript aber angeblich nur vom Browser interpretiert wird, ist es eben keine Programmiersprache.

Die Aufgabe:
Liefere Beweise oder Gegenbeweise dafür, dass JavaScript eine Programmiersprache ist.
Widerlege oder bestätige oben genannte Definition von "Programmiersprache".

bye, Frank!

ps. Er ist darüber hinaus der Meinung, japanische Schriftzeichen wären keine Schriftzeichen, da sie mit einem Pinsel gemalt werden, statt mit einem Stift geschrieben. Soviel zur Kontrolle seines Seelenzustandes ;))

  1. Moin!

    Wir haben gerade ein schwerwiegendes Problem im Chat:

    Das hab ich mir schon gedacht, als ich nur den Titel gelesen hab *g*

    Was sind Programmiersprachen bzw. ist JavaScript eine Programmiersprache?

    Naja, eigentlich hatten wir das ja schon mal: <../../sfarchiv/1999_2/t03805.htm>.

    Meine vorgeschlagene Definition von Prorgrammiersprache war folgende:
    Eine Programmiersprache ist eine Kunstsprache, die dem Anwender hilft, dem Computer Algorithmen in einer dem Computer verständlichen Form zu vermitteln.

    Na wenn Du das als Grundlage nimmst, ist bietet sogar die Bourne-Shell eine Programmiersprache.

    Leider ist Sebastian nicht ganz meiner Meinung. Er findet, eine Programmiersprache definiert sich einzig und alleine aus ihrer Weiterverarbeitung: es handelt sich also nur um eine Programmiersprache, wenn sie vor der Ausführung kompiliert wird, so wie C, Pascal, Perl und so weiter. Da JavaScript aber angeblich nur vom Browser interpretiert wird, ist es eben keine Programmiersprache.

    Es waere nicht schwer, einen JS-Compiler zu schreiben. In der Tat muesste man nur einen C++-Compiler nehmen, den etwas anwenderfreundlicher (oder auch idiotensicherer) machen, und auf einmal ist JS dann also doch eine Programmiersprache.

    Liefere Beweise oder Gegenbeweise dafür, dass JavaScript eine Programmiersprache ist.

    Siehe oben. Andere Definitionen von Programmiersprache machen natuerlich andere (Gegen-)Beweise erforderlich oder aendern das Ergebnis sowieso.

    Widerlege oder bestätige oben genannte Definition von "Programmiersprache".

    Ehrlich gesagt, solche Definitionen sind mir voellig egal. Ich weiss, womit ich was anfangen kann, und das reicht erst mal. Und deshalb ist z.B. Basic fuer mich keine Programmiersprache, da sie nicht mal die simpelsten Dinge wie Pointer beherrscht, was das Implementieren diverser Algorithmen erheblich erschwert, wenn nicht gar unmoeglich macht. Da ich JS noch nie ausserhalb eines Browserfensters verwendet habe, stellt sich die Frage dort fuer mich gar nicht.

    ps. Er ist darüber hinaus der Meinung, japanische Schriftzeichen wären keine Schriftzeichen, da sie mit einem Pinsel gemalt werden, statt mit einem Stift geschrieben.

    Aeh.. so so

    Calocybe

    1. Moin Calocybe,

      Ehrlich gesagt, solche Definitionen sind mir voellig egal. Ich weiss, womit ich was anfangen kann, und das reicht erst mal. Und deshalb ist z.B. Basic fuer mich keine Programmiersprache, da sie nicht mal die simpelsten Dinge wie Pointer beherrscht, was das Implementieren diverser...

      ich kann mich aber noch dunkel an diese schönen Basic-Befehle 'Poke' und 'Peek' erinnern. Damit kann man doch im Grunde alles machen, was man auch mit Pointern machen kann oder? Ok - man konnte "damals" noch keinen Speicher reservieren, braucht man ja auch nicht, wenn 'Poke' auch so funktioniert - ist eh viel spannender ;-))

      Bis dannundwann...

      Andreas

      1. hi!

        [BASIC]

        ich kann mich aber noch dunkel an diese schönen Basic-Befehle 'Poke' und 'Peek' erinnern.
        Damit kann man doch im Grunde alles machen, was man auch mit Pointern machen kann
        oder? Ok - man konnte "damals" noch keinen Speicher reservieren, braucht man ja auch
        nicht, wenn 'Poke' auch so funktioniert - ist eh viel spannender ;-))

        Mit bestimmten BASIC-Dialekten kann man sogar DOS-Interrupts etc. ausführen. Man muss nur den Code in Maschinensprache direkt in den Speicher schreiben, und dann an die jeweilige Adresse im Speicher springen, um den Code auszuführen :-)

        bye, Frank!

      2. Hi Andreas!

        ich kann mich aber noch dunkel an diese schönen Basic-Befehle 'Poke' und 'Peek' erinnern.

        Ja, dunkel. Die dienen zum direkten Lesen und Beschreiben einer Adresse, ne?

        Damit kann man doch im Grunde alles machen, was man auch mit Pointern machen kann oder?

        Wenn Du dann auch noch die Adresse einer Variablen herausfinden kannst - ja. Man will ja nicht *nur* mit peek und poke arbeiten, zuweilen reichen ja auch die ganz normalen Mittel. Sonst kannst Du ja gleich assemblern. Da ziehe ich dann aber einen richtigen ASM vor.

        Ok - man konnte "damals" noch keinen Speicher reservieren, braucht man ja auch nicht, wenn 'Poke' auch so funktioniert - ist eh viel spannender ;-))

        Spannender, und nichts fuer Warmduscher, das kann man wohl sagen. *g*

        Bye, Calocybe

  2. Hallo,

    Wir haben gerade ein schwerwiegendes Problem im Chat: Was sind Programmiersprachen bzw. ist JavaScript eine Programmiersprache?

    Meine vorgeschlagene Definition von Prorgrammiersprache war folgende:
    Eine Programmiersprache ist eine Kunstsprache, die dem Anwender hilft, dem Computer Algorithmen in einer dem Computer verständlichen Form zu vermitteln.

    Finde ich sehr treffend. Auch wenn man vielleicht für Algorithmen vielleicht ein anderes Wort finden könnte.

    .... Da JavaScript aber angeblich nur vom Browser interpretiert wird, ist es eben keine Programmiersprache.

    Meines erachtens wirkt hier der Browser als Compiler. Der Unterscheid zum herkömmlichen Compiler ist nur, daß das Resultat des "Programms" direkt auf dem Bildschrim ausgegeben wird und der herkömmliche Compiler sein Ergebnis auf der Festplatte speichert und bei Aufruf auf dem Bildschrim ausgibt. (Mit Bildschrimausgabe sind auch alle anderen Interaktionen gemeint)

    ps. Er ist darüber hinaus der Meinung, japanische Schriftzeichen wären keine Schriftzeichen, da sie mit einem Pinsel gemalt werden, statt mit einem Stift geschrieben.

    Und warum heißen Sie dann Schriftzeichen? Jeder, der diese "Schrift" erlernt hat kann sie lesen und schreiben. Wo besteht, außer der Vielzahl, der anderen Form und das von oben nach unten geschrieben und gelesen wird, sonst der Unterschied zur westlichen oder abendländischen Schrift.

    Gruß HaPe

  3. Mal was anderes:

    Wieso machen sich Menschen darüber Gedanken, ob JavaScript eine Programmiersprache ist, ob man jemanden, der HTML-Seiten erstellt, Programmierer nennen darf?
    Ganz einfach: Es sollen Werte gefunden werden. D.h.: "Du bist ja gar kein Programmierer, JavaScript ist doch 'ne Babysprache..."
    Daß dem nicht so ist, erleben wir doch in diesem Forum.
    Mein Kumpel will mir auch immer aufzeigen, daß DELPHI DIE Programmiersprache wäre.
    Worum geht es eigentlich? Meiner Meinung nach sollen alle Sprachen doch wohl ein Problem lösen! Nimmt man bspw. Perl, so kann man natürlich sagen, daß es nicht das schnellste ist, aber es ist durchsichtig. Denn es ist weder Compiler- noch Interpretersprache, sondern ein bischen von beidem. Aber das ist auch alles egal, es kommt doch darauf an, was man machen möchte!

    Ich finde solches Denken frustrierend, man wird überall unterschwellig damit konfrontiert. Bestes Beispiel ist ja auch des deutschen liebste Waffe "Auto".
    Mich nervt es auch wenn so'n beklopptes "Swatch"-Auto den ganzen Verkehr aufhält, aber in der Summe ist es viel nerviger, WIE die Leute alle fahren. Wenn jeder den anderen (komischen) Autotyp akzeptieren würde, hätten wir weniger Probleme/Stau auf der Straße.
    Oder ist es nicht so, daß oftmals ein größerer Wagen (Namen spare man sich) mit Absicht nicht vorbeigelassen wird, genauso wie der Fahrer des "größeren" Wagens es den Fahrern des "kleineren" zeigen will. Ich will das nicht pauschalisieren, aber insgesamt sieht es oft so aus.

    Nach dem Abschweif...
    Was ist also der Hintergrund, sich darüber überhaupt Gedanken zu machen? Es kommt wohl darauf an, ob es derzeit möglich ist, dies und das mit JS zu realisieren, ob es der Server vielleicht selbst kann, oder ob man etwas wie Perl benötigt.
    Viele C-Programmierer meinen meist, C wäre DIE Programmiersprache. Der Grund ist oft, daß man darin einen solchen Wurschtelcode schreiben kann, daß es kein anderer mehr versteht.
    Dieses mußte ich auch an meiner Uni erfahren: Mein Info-Prof. konnte zwar selbst nicht ordentlich programmieren, war aber der Meinung, daß man den Syntax so aus dem effeff können muß, daß man Pointer-auf-Array-das-wieder-auf-Pointer-verweist-blablabla verstehen muß, selbst, wenn dieses in der Praxis wahrscheinlich eher anders programmiert würde.....

    Reiner

  4. Hi,

    Leider ist Sebastian nicht ganz meiner Meinung. Er findet, eine Programmiersprache definiert sich einzig und alleine aus ihrer Weiterverarbeitung: es handelt sich also nur um eine Programmiersprache, wenn sie vor der Ausführung kompiliert wird,

    wenn diese Unterscheidung der einzige Grund ist, warum JavaScript keine Programmiersprache sein soll: Eine jede(!) interpretierte Sprache kann auch kompiliert werden. Ob man ein kompiliertes JavaScript-Programm im Browser verwenden kann ist eine andere Sache; vermutlich geht es über <object> oder so. Auf jeden Fall hält diese Bedingung keiner Untersuchung stand.

    Cheatah

  5. Ein Programm ist eine Sammlung/Aneinanderreihung von Wörtern, die einen Computer veranlassen, irgendwelche Aktionen auszuführen. Die Programmiersprache ist die Menge aller möglichen Wörter für dieses Programm.
    Um ein Programm zu verstehen, braucht der Computer einen "Übersetzer", dass kann ein Compiler (der Übersetzer übersetzt das Programm komplett vor der Ausführung in "Computersprache") oder ein Interpreter (der Übersetzer übersetzt das Programm direkt während der Ausführung Satz für Satz) sein.
    In diesem Sinne ist also Javascript eine Programmiersprache.
    Etwas wissenschaftlicher ausgedrückt findet man es sicher auch in jedem Informatik-Lehrbuch...

  6. Hallo Frank

    Wir haben gerade ein schwerwiegendes Problem im Chat: Was sind Programmiersprachen bzw. ist JavaScript eine Programmiersprache?

    Wenn ich mich recht entsinne, verwenden die Profis doch gerne das Charakteristikum, ob eine Sprache ueber Kontrollstrukturen und Sprungbefehle verfuegt, als entscheidend fuer die Eindordnung "Programmiersprache" oder nicht. Da HTML selber beispielsweise keine if's oder while's oder goto's kennt (sehen wir mal von so Spitzfindigkeiten wie <noframes>, <noscript> oder <noembed> ab *g*), gilt es eben _nicht_ als Programmiersprache, waehrend JavaScript ueber das gesamte klassische Instrumentarium der bedingten Ausfuehrung von Anweisungen verfuegt.
    Wer das Programm nun letztendlich ausfuehrt, ist aus dieser Sicht eigentlich sekundaer. Das "Compilieren" und "Linken" von Code ist doch nur ein Optimierungsschritt fuer mehr Ausfuehrungsgeschwindigkeit.

    viele Gruesse
      Stefan Muenz

    1. Wenn ich mich recht entsinne, verwenden die Profis doch gerne das Charakteristikum, ob eine Sprache ueber Kontrollstrukturen und Sprungbefehle verfuegt, als entscheidend fuer die Eindordnung "Programmiersprache" oder nicht. Da HTML selber beispielsweise keine if's oder while's oder goto's kennt (sehen wir mal von so Spitzfindigkeiten wie <noframes>, <noscript> oder <noembed> ab *g*), gilt es eben _nicht_ als Programmiersprache,

      HTML wird auch recht eindeutig geparst und nicht direkt interpretiert. Hier ist es sogar ganz offensichtlich. Schwerer wird es dann schon bei (La)TeX, was ja als Satzsystem mit Auszeichnungen arbeitet, allerding viel unmittelbarer Befehle (auch Bedingungen und Schleifen) zur Verarbeitung schickt. Trotzdem wird es wohl niemand als Programmiersprache bezeichnen.

      Ich sehe da durchaus fliessende Grenzen. Allerdings gibt es ja auch Anforderungen an Syntax und Grammatik einer Sprache, um eine Programmiersprache zu sein. Leider sind mir diese nicht gelaeufig.

      Viele Gruesse, Thomas Hieck

  7. Hi Frank.

    hi!

    Wir haben gerade ein schwerwiegendes Problem im Chat: Was sind Programmiersprachen bzw. ist JavaScript eine Programmiersprache?

    Meine vorgeschlagene Definition von Prorgrammiersprache war folgende:
    Eine Programmiersprache ist eine Kunstsprache, die dem Anwender hilft, dem Computer Algorithmen in einer dem Computer verständlichen Form zu vermitteln.

    Nun, die Def. ist auf jeden Fall nicht besonders strikt. Schliesslich muss letztendlich _alles_, d.h. auch ein Algo, erst in eine andere Form ( 'dem Computer verständlich' ) gebracht werden.
    Denk doch mal an einen 'ls -lFa'...und eine Shell ist garantiert keine Sprache.

    Die Aufgabe:
    Liefere Beweise oder Gegenbeweise dafür, dass JavaScript eine Programmiersprache ist.
    Widerlege oder bestätige oben genannte Definition von "Programmiersprache".

    Normalerweise unterscheidet man in solchen Faellen zwischen Makro- und Programmiersprachen. Im Falle JScript ist das recht klar - bei Makrosprachen
    werden nur vorhandene Konstrukte ( 'Befehle' ) benutzt, um eine auf ein spezielles Ziel ausgerichtete Wirkung zu erlangen ( s. z.B. das image-Objekt etc. ). In C/C++ o.ae. z.B.
    existieren natuerlich auch Unmengen von Libs bzw. Templates, um beispielsweise einen Befehlssatz zu erhalten, der gezielt Bilder manipuliert usw. Allerdings fehlt bei JScript die Erweiterbarkeit ( da es nicht darauf ausgerichtet ist ). Komplexe Strukturbildung ist nicht moeglich etc.
    Also ist JScript eine Sprache, und zwar eine Makrosprache ( deswegen heisst es ja auch
    Java*Script*, hehe ).

    bye, Frank!

    Ciao, Christian

    ps. Er ist darüber hinaus der Meinung, japanische Schriftzeichen wären keine Schriftzeichen, da sie mit einem Pinsel gemalt werden, statt mit einem Stift geschrieben. Soviel zur Kontrolle seines Seelenzustandes ;))

    erg...also das ist dann doch schon Pedanterie, oder ;-)

    1. Denk doch mal an einen 'ls -lFa'...und eine Shell ist garantiert keine Sprache.

      Oha!

      Eine Shell hat Variablen und mächtige Kontrollstrukturen, mit denen man durchaus komplexe Algorithmen beschreiben kann.
      Und interpretiert wird eine Shelle genau wie Perl.

      Also: Wieso soll "shell" keine Programmiersprache sein? Die "Shell" selbst ist der Interpreter dazu.

      1. Hi,

        Denk doch mal an einen 'ls -lFa'...und eine Shell ist garantiert keine Sprache.

        Oha!

        Eine Shell hat Variablen und mächtige Kontrollstrukturen, mit denen man durchaus komplexe Algorithmen beschreiben kann.
        Und interpretiert wird eine Shelle genau wie Perl.

        Also: Wieso soll "shell" keine Programmiersprache sein? Die "Shell" selbst ist der Interpreter dazu.

        Nun, normalerweise ist eine heutige Shell aus einem CLI ( command line interpreter ) hervorgegangen. D.h. was eine Shell macht, ist einfach Parameter an externe ( auch interne ) Kommandos, sprich Programme, zu übergeben. Die Behandlung dieser Parameter ist tatsächlich äusserst komplex ( reguläre Ausdrücke, Variablen, bedingte Anweisungen etc. ),
        aber eine Shell ist keine Programmiersprache ( meine Def. kennst du ja... ).

        Christian

        1. Nun, normalerweise ist eine heutige Shell aus einem CLI ( command line interpreter ) hervorgegangen. D.h. was eine Shell macht, ist einfach Parameter an externe ( auch interne ) Kommandos, sprich Programme, zu übergeben. Die Behandlung dieser Parameter ist tatsächlich äusserst komplex ( reguläre Ausdrücke, Variablen, bedingte Anweisungen etc. ),
          aber eine Shell ist keine Programmiersprache ( meine Def. kennst du ja... ).

          Was ich meinte, ist: "Shell" unterscheidet sich in keinem m. E. wesentlichen Punkt von Perl oder Basic oder anderen Interpretersprachen.
          Eine Shell macht Syntaxanalyse (wie Perl), sie hat Variablen und Kontrollstrukturen (wie Perl), sie führt einige Sachen selbst aus (wie Perl; die Korn-Shell interpretiert "if" selbst, das kannst Du mit "whence if" überprüfen) und überläßt andere Sachen dem Betriebssystem (wie Perl über backticks). (Überhaupt ist ja Perl als Obermenge von shell, C und awk entstanden.)

  8. Hi,

    ich denke nicht, dass man eine Programmiersprache darüber definieren kann, ob sie nun kompiliert oder interpretiert wird.

    Wenn man sagt, dass eine Programmierprache kompiliert wird, fallen Sprachen wie Basic oder die Batch-Programmierung (*programmierung**eg*) raus.

    Da trifft dann eher das zu, was Stefan gesagt hat.

    Schönen Gruß

    Thomas

    PS: Und jetzt bitte nicht streiten, ob Basic 'ne Programmiersprache oder ein Zustand ist ;-)

  9. hallo Ihr Hirn-Zerfurcher,

    Wir haben gerade ein schwerwiegendes Problem im Chat: Was sind Programmiersprachen bzw. ist JavaScript eine Programmiersprache?

    ich finde schon wichtig, daß man sich über die Unterschiede Gedanken macht, ich habe noch in der Schule und auf der Uni gelernt, daß eine genaue Ausdrucksweise und Unterscheidungsfähigkeit das klare Denken fördert,  und präzise Definitionen wissenschaftlichem Arbeiten  förderlich sind. Im Berufsleben habe ich dann gelernt, daß das auch im Alltag (Berufsleben = Alltag) gilt <g>

    ein wichtiger Unterschied zwischen Makro-Sprache und Programmiersprache wurde hier noch nicht genannt:

    ich versuche es mal zu formulieren, schlagt mich nicht, wenn es vielleicht nicht ganz präzise formuliert ist, (ich habe gerade eine anstrengende Mittagspause...), das Prinzip wird deutlich

    eine Programmiersprache erzeugt "auf dem Betriebssystem-Kernel selbst ablaufenden Code mit eigener interner Befehlssprache (also keine DOS-Batches...) ", d.h. es muß außer dem Betriebssystem nicht noch ein Ablaufsteuerndes Programm installiert sein, in der PC-Welt sind das dann EXE-Files oder DLLs, die von EXEs geholt werden.

    eine Makrosprache erzeugt "Anweisungsbündel", die von einem auf dem Betriebssystem installierten Programm gestartet, interpretiert und ausgeführt werden....
    Perl-Scripte vom PERL-Interpreter
    VB-Scripte von entsprechenden MS-EXEs oder DLLs
    REBOL-Scripte vom REBOL-Interpreter
    JAVASCRIPT vom Browser, der den HTML-Code abarbeitet...
    ....

    glaubt Ihr mir das?

    Gruss Connie

    1. hi!

      eine Programmiersprache erzeugt "auf dem Betriebssystem-Kernel selbst ablaufenden Code
      mit eigener interner Befehlssprache (also keine DOS-Batches...) ", d.h. es muß außer dem
      Betriebssystem nicht noch ein Ablaufsteuerndes Programm installiert sein, in der PC-Welt
      sind das dann EXE-Files oder DLLs, die von EXEs geholt werden.
      eine Makrosprache erzeugt "Anweisungsbündel", die von einem auf dem Betriebssystem
      installierten Programm gestartet, interpretiert und ausgeführt werden....

      Was ist zb. mit Java? Java erzeugt bei der Kompilierung einen Bytecode, der später bei der Ausführung von einem aufs jeweilige Betriebssystem zugeschnittenen Interpreter interpretiert wird und erst dann in Code umgewandelt wird, der vom Kernel ausgeführt werden kann. Ist Java jetzt eine Programmiersprache oder eine Makrosprache? :)

      Perl-Scripte vom PERL-Interpreter
      VB-Scripte von entsprechenden MS-EXEs oder DLLs
      REBOL-Scripte vom REBOL-Interpreter
      JAVASCRIPT vom Browser, der den HTML-Code abarbeitet...
      glaubt Ihr mir das?

      Perl-Skripte werden vor ihrer Ausführung vom Perl-Interpreter kompiliert und dann ausgeführt. Der Unterschied zum Java-Bytecode ist, dass sie unmittelbar vor der Ausführung noch in reiner ASCII-Form vorliegen.

      Ich weiß nicht, ob ich das schon geschrieben habe, aber meiner Meinung nach hat die Definition von Programmiersprache nichts damit zu tun, wie sie weiterverarbeitet wird. Letztendlich wird auch der endgültige ausführbare Code vom Kernel oder später vom Prozessor interpretiert. Wo die Interpretation stattfindet und in welcher Form der Code dann vorliegt ist doch im Grunde genommen egal.

      bye, Frank!

      1. Was ist zb. mit Java? Java erzeugt bei der Kompilierung einen Bytecode, der später bei der Ausführung von einem aufs jeweilige Betriebssystem zugeschnittenen Interpreter interpretiert wird und erst dann in Code umgewandelt wird, der vom Kernel ausgeführt werden kann. Ist Java jetzt eine Programmiersprache oder eine Makrosprache? :)

        tja, eigentlich wäre JAVA eine "Programmiersprache" im von mir definiertem Sinne, wenn es eben nur auf einem Betriebssystem laufen täte...
        meine Definition stammt noch aus der Zeit, als eine Programmiersprache für ein Betriebssystem schrieb und kompilierte...
        dann kamen etliche Sprachen, die mehrere Betriebssysteme als Zielplattform hatten und eben jeweils extra für dieses System kompiliert wurden oder  wie eben JAVA noch einen Zwischenübersetzer benötigen...

        die Zeiten ändern sich, manche Definitionen (wie meine) veralten... <g>
        aber ich sehe noch einen Unterschied:

        Programmiersprachen haben ihre eigenen Befehle, Funktionen, Funktionsweisen, Syntax etc.
        die Scriptsprachen bestehen meistens aus einem dialekgefärbten SubSet von C++ oder ähnlichen 'Hochsprachen'   -> was meint Ihr dazu?

        Gruss
        Connie

    2. Hallo Connie

      eine Programmiersprache erzeugt "auf dem Betriebssystem-Kernel selbst ablaufenden Code mit eigener interner Befehlssprache (also keine DOS-Batches...) ", d.h. es muß außer dem Betriebssystem nicht noch ein Ablaufsteuerndes Programm installiert sein

      Hmm - damit bindest du Programmierung und Betriebssystem zusammen. Aber was spricht dagegen, auch andere Interpreter als Betriebssystem-Interpreter zuzulassen? Das Betriebssystem ist doch einfach nur eine "Schicht" im ganzen Computer-Sediment - darunter liegen Hardware-Schaltungen, und darueber liegen Betriebssystemoberflaechen und Anwendungen.

      Ich bin mal so frei und behaupte etwas salopp: Programmierung ist, wenn es bei normalen Leuten erst mal aussetzt. Einfachstes Beispiel: HTML versteht fast jeder auf Anhieb. JavaScript dagegen verstehen nur wenige sofort (auch wenn es viele auf ihren Seiten einsetzen <g>).

      In der Programmierung hast du einfach andere Probleme als in rein beschreibenden Sprachen. Wenn du ein Problem hast wie: "wie bekomme ich die Eintraege dieser Liste sortiert, und zwar absteigend nach der 24. Stelle in den Zeichenketten sortiert" - dann bist du erst mal nicht so sehr damit beschaeftigt, welchen Befehl du nun notieren musst, sondern du musst dir erst mal vorstellen, was da genau Schritt fuer Schritt passieren soll. Erst wenn du eine Schritt-fuer-Schritt-Loesung gefunden hast, macht es Sinn, sich darueber Gedanken zu machen, welche Befehle der Sprache du dazu brauchen kannst. Diese Vorgehensweise wuerde ich als Programmierung bezeichnen.
      Was nun Programmiersprachen sind? Nun ja, ich wuerde sagen, alle Sprachen, mit der diese Art Vorgehensweise unterstuetzt, die es erlaubt, gefundene Schritt-fuer-Schritt-Loesungen in einen Satz von Befehlen umzusetzen.

      viele Gruesse
        Stefan Muenz

      1. In der Programmierung hast du einfach andere Probleme als in rein beschreibenden Sprachen. Wenn du ein Problem hast wie: "wie bekomme ich die Eintraege dieser Liste sortiert, und zwar absteigend nach der 24. Stelle in den Zeichenketten sortiert" - dann bist du erst mal nicht so sehr damit beschaeftigt, welchen Befehl du nun notieren musst, sondern du musst dir erst mal vorstellen, was da genau Schritt fuer Schritt passieren soll. Erst wenn du eine Schritt-fuer-Schritt-Loesung gefunden hast, macht es Sinn, sich darueber Gedanken zu machen, welche Befehle der Sprache du dazu brauchen kannst. Diese Vorgehensweise wuerde ich als Programmierung bezeichnen.

        Hm, damit hebst Du im Wesentlichen auf den Algorithmus-Begriff ab, der ja auch von Frank genannt wurde. Der gilt aber höchstens für 3GL (Programmiersprachen der 3. Generation), nicht für 4GL.
        4GL-Sprachen versuchen gerade, dieses algorithmische Denken zu umgehen (mit der Idee, daß man eben gerade *nicht* "Programmieren" im herkömmlichen Sinne gelernt haben muß ...), indem man nicht mehr beschreibt, *wie* man zu einem Ergebnis kommt, sondern welche *Eigenschaften* das Ergebnis haben soll.
        Prominente Vertreter dieser Sorte:

        • SQL ("select * from <tablename> where <feldname/gt; = '42';" - was kümmert mich, *wie* er das macht?) oder
        • Prolog.

        Und 4GL-Sprachen haben normalerweise eben gerade nicht mehr die Eigenschaften, die für 3GL-Sprachen genannt wurden, etwa Verzweigungen oder Schleifen. (Diese braucht man ja nur für Algorithmen, also mehr oder weniger sequentielle Ablaufpläne.)

        1. Hallo Michael

          Hm, damit hebst Du im Wesentlichen auf den Algorithmus-Begriff ab, der ja auch von Frank genannt wurde. Der gilt aber höchstens für 3GL (Programmiersprachen der 3. Generation), nicht für 4GL.
          4GL-Sprachen versuchen gerade, dieses algorithmische Denken zu umgehen (mit der Idee, daß man eben gerade *nicht* "Programmieren" im herkömmlichen Sinne gelernt haben muß ...), indem man nicht mehr beschreibt, *wie* man zu einem Ergebnis kommt, sondern welche *Eigenschaften* das Ergebnis haben soll.

          Das klingt gut - so aehnlich wie "das Ziel ist der Weg"! Wahrscheinlich kann ich das nur deshalb nicht so ganz nachvollziehen, weil ich mich bislang mit keiner 4GL-Sprache naeher beschaeftigt habe. Aber wenn man nun mal ein spezielles Problem zu loesen hat wie beispielsweise das Sortieren von Zeilen ab einer bestimmten Zeichenposition, und die Programmiersprache haelt fuer dieses Problem keinen fertigen Funktionsaufruf in der Form sort(Liste,abZeichen24) bereit, dann musst du dir eben irgendwas einfallen lassen, oder nicht? Ist das denn in 4GL-Sprachen nicht auch so? Ich habe eher den Eindruck, dort darf man manche Probleme einfach nicht artikulieren, weil sie nicht ins Sprachkorsett passen <g>.

          viele Gruesse
            Stefan Muenz

          1. Aber wenn man nun mal ein spezielles Problem zu loesen hat wie beispielsweise das Sortieren von Zeilen ab einer bestimmten Zeichenposition, und die Programmiersprache haelt fuer dieses Problem keinen fertigen Funktionsaufruf in der Form sort(Liste,abZeichen24) bereit, dann musst du dir eben irgendwas einfallen lassen, oder nicht? Ist das denn in 4GL-Sprachen nicht auch so?

            Wenn jede Programmiersprache für jedes Problem gleich gut geeignet wäre (oder eine für alle Probleme!), dann gäbe es nicht so viele verschiedene Programmiersprachen ;-)

            Es gab über die Jahrzehnte immer wieder Versuche, die eierlegende Wollmilchsau der Programmiersprachen zu erschaffen (PL/I in den 70er Jahren, ADA vom US-Militär in den 80ern), aber der unvermeidliche trade-off ist, daß man entweder durch zu wenige Befehle eingeschränkt (Standard-Pascal, da gibt es nicht mal eine definierte Schnittstelle zu Dateien des Betriebssystems!) oder durch zu viele Befehle überfordert wird (die genannten Sprachen).

            Die Konsequenz waren Sprachen wie C oder Perl: Kleiner Sprachkern plus Bibliotheken.
            Man konnte also für einfache Probleme schnell eine Lösung schreiben, während man für schwierige Probleme einfach die Mächtigkeit der Sprache erweitern (bzw. solche Erweiterungen dazu kaufen) konnte. (Objektorientierte Sprachen mit ihren Klassenbibliotheken schlagen in dieselbe Kerbe, bringend lediglich mehr Disziplin und eine einheitlichere Syntax.)

            Ich habe eher den Eindruck, dort darf man manche Probleme einfach nicht artikulieren, weil sie nicht ins Sprachkorsett passen <g>.

            Völlig richtig. Mit SQL einen Editor zu schreiben ist etwa so elegant wie mit zwei Spitzhacken einen Wollpullover zu stricken.

            Konkret bei SQL lassen sich allerdings einige Probleme dadurch lösen, daß man die Algorithmen nicht in der Sprache zur Ausgabe der Ergebnisse einbaut, sondern in die Datenbank selbst (intelligente Tabellen: Trigger, Constraints usw.). Wieso eine Konsistenzprüfung über den Datenbank inhalt in 10 verschiedenen Anwendungen, wenn man das auch einmal in der Datenbank erledigen kann? Die Anwendungsprogramme in 4GL-DML bleiben kurz und knapp, wenn die Datenstrukturen in DDL und 3GL schlau genug sind.

            Zudem gibt es Hybridsprachen:

            • Pro*C (Oracle) ist eine Obermenge von C, in der man durch bestimmte Metasyntax SQL-Anweisungen in den Quelltext schreiben kann; ein Precompiler ersetzt dies dann durch einen C-Quelltext mit Funktionsaufrufen der Oracle-API, der normal weiterübersetzt werden kann.
            • PL*SQL (Oracle) hingegen ist eine Pascal-ähnliche Sprache mit Variablen und Kontrollstrukturen, aber man kann auch direkt SQL-Anweisungen darin verwenden und die Ausgabe über Funktionen an Variablen zuweisen ... und PL*SQL-Programme (Funktionen) kann man wiederum in der Datenbank abspeichern und in SQL-Anweisungen (DDL und DML!) als Funktionsaufrufe ansprechen.

            Früher befaßte man sich noch mehr als heute mit Problemen wie

            • Aufruf von Maschinensprachenroutinen aus einer Hochsprache oder
            • Aufruf einer mathematischen Funktion aus einer Fortran-Bibliothek mit hochgenauer Zahldarstellung durch ein C-Programm
              usw. - in C gibt es noch heute irgendwelche inlining-Möglichkeiten für Maschinensprache.
              Erst seitdem Portabilität und Transparenz durch die wachsende Komplexität (wieviele Zeilen hat der Windows-Quelltext?) der Programme und die höhere Reevanz kaufmännischen Denkens bei der Softwareerstellung (die ersten Programmierer wollten ihre Programme nicht verkaufen, sondern laufen lassen!) immer wichtiger wurde, entfernte man dieses Feature wieder aus den Sprachdefinitionen; heute überläßt man die Verbindung von Programmen verschiedener Programmiersprachen sinnvollerweise dem Betriebssystem (DLL-Schnittstelle etc.).
            1. Moin ;-)

              heute überläßt man die Verbindung von
              Programmen verschiedener Programmiersprachen sinnvollerweise dem Betriebssystem
              (DLL-Schnittstelle etc.).

              Ich würde an dieser Stelle mal meine Vermutung kundtun, daß in den kommenden Jahren immer mehr Skriptsprachen auch für große Anwendungen verwendet werden (ok - wenn das in 5 Jahren nicht stimmt, könnt ihr mich gerne auf dieses Posting hier hinweisen <g>). Gründe:

              • Skripte lassen sich schnell entwickeln, da das compilieren und linken entfällt.
              • Die Rechner werden so schnell, daß die Ausführungsgeschwindigkeit gegenüber der Entwicklungszeit immer mehr an Bedeutung verliert.
              • In Skriptsprachen kann man sich zu nutze machen, daß der "Parser" (Interpreter/Übersetzer) auch zur Ausführungszeit aktiv ist und z.B. viel mehr "in Worten" programmieren (vgl. z.B. der 'eval'-Befehl in Javascript). Auch kann man z.B. Formeln auf leichteste Weise zur Laufzeit parsen lassen, so daß der Benutzer einer Anwendung z.B. statt Zahlen auch Formelausdrücke in irgendwelche Eingabefelder eingeben kann usw...

              Naja - soweit meine Prophezeiungen für die Zukunft <g>.

              Ansonsten kann ich zum Thema "Programmiersprachen" nur wieder an die "Turing-Maschine" erinnern. Siehe dazu der Archivlink im Posting von Calocybe und - nur für eingefleischte Beta-Tester, noch ohne Doku usw. - http://www.stud.uni-hannover.de/~bierhals/tmp/turing/ (bitte nicht mit ie5 testen, ihr wißt schon, das Problem mit dem Cache-Bug und den .gifs ....)

              Bis dannundwann...

              Andreas

              1. Ich würde an dieser Stelle mal meine Vermutung kundtun, daß in den kommenden Jahren immer mehr Skriptsprachen auch für große Anwendungen verwendet werden.

                Hm - mit "Skriptsprachen" meinst Du "interpetierte Sprachen"? Letzten Endes ist es doch gar keine Eigenschaft der Sprache, ob sie interpretiert oder kopmiliert wird. Du kannst sehr wohl einen C-Interpreter schreiben ... das wird halt keiner wollen, weil C-Programmierer keine Angst vor Übersetzen und Binden haben. ;-)

                Gründe:

                • Skripte lassen sich schnell entwickeln, da das compilieren und linken entfällt.

                (gulp ...) Ich lasse auch meine Perl-Skripte "kompilieren" - ich habe zu jedem Skript meines Projekts eine Batch-Datei, die "perl -c" für dieses Skript ausführt.
                Ich möchte meine Fehler nämlich selbst finden und das nicht dem Kunden überlassen. ("Bananen-Software")

                • Die Rechner werden so schnell, daß die Ausführungsgeschwindigkeit gegenüber der Entwicklungszeit immer mehr an Bedeutung verliert.

                Das mag für Anwendungen für einzelne Benutzer gelten (die dezentrale Rechenkraft ist durch das Client-Server-Prinzip in der Tat immens gestiegen), aber für Server-Anwendungen mit tausenden von Benutzern wird man weiterhin optimieren (müssen).

                • In Skriptsprachen kann man sich zu nutze machen, daß der "Parser" (Interpreter/Übersetzer) auch zur Ausführungszeit aktiv ist und z.B. viel mehr "in Worten" programmieren (vgl. z.B. der 'eval'-Befehl in Javascript).

                Das hat doch nichts damit zu tun, ob die Sprache interpretiert wird oder nicht!
                Auch in einer Compilersprache könnte man eine eval-Funktion schreiben und per Bibliothek zu jedem beliebigen Programm hinzubinden. Man muß es nur tun (wollen) ...

                Auch kann man z.B. Formeln auf leichteste Weise zur Laufzeit parsen lassen, so daß der Benutzer einer Anwendung z.B. statt Zahlen auch Formelausdrücke in irgendwelche Eingabefelder eingeben kann usw...

                Auch das hat nichts mit der Programmiersprache zu tun, sondern mit dem Komfort einer Anwendung.
                Ob ich in einem HTML-Formular JavaScript-Routinen für die Syntaxanalyse einer Formulareingabe anbiete oder nicht, ist meine Entscheidung, nicht aber eine Eigenschaft von HTML oder JavaScript.

                Ich teile Deine Vorhersage nur insofern, als daß in fünf Jahren wieder ganz *andere* Sprachen in Mode sein werden als heute. Aber auch heute programmiert man noch in C, was eine schon ziemlich alte Sprache ist - also werden wir unser aktuelles Perl-Wissen auch in fünf Jahren noch brauchen können.

                Meine "Vorhersage" ist, daß die Zahl der (oftmals proprietären) Programmiersprachen nicht kleiner werden wird als bisher, daß der durchschnittliche Programmierer aber mehr verschiedene Sprachen verwenden muß als bisher. Und dabei zähle ich Sprachen etwa zur Programmierung von Word- oder Excel-Makros mit!
                Konsequenterweise wird der Sprachkern fast aller neuen Sprachen klein sein (kurze Anlernzeit - Schulung ist teuer!); das Lernen einer Sprache wird mehr darin bestehen, die Semantik der zugrundeliegenden Anwendung zu verstehen (das Komplexe an SQL ist keineswegs die Syntax, sondern die Struktur und die Fähigkeiten des darunterliegenden Relationalen Datenbanksystems).

                Man wird also bei seiner Ausbildung noch mehr Wert darauf legen müssen, "lernen" zu lernen, also ständig neue spezialisierte Werkzeuge einzusetzen.
                Insofern ist das Konzept der "Energie des Verstehens" genau das, was ich jedem empfehlen kann, der "am Ball bleiben" will: Nicht die Syntax ist letztlich interessant, sondern die damit umsetzbaren Konzepte.

                Die Grenze zwischen "anwenden" (Menü-Klickerei) und "programmieren" (Anweisungen in Dateien schreiben) wird mehr und mehr verschwimmen, weil viele Dinge auf beiden Ebenen möglich sein werden. Als Beispiele nenne ich hier ganz bewußt

                • WYSIWYG-Generatoren für Web-Dokumente (gerade hier verschwimmt ja die Grenze zwischen Gestalten und Programmieren, was auch der Anlaß für diesen thread war) oder
                • Report-Generatoren für Datenbankabfragen (da kann man schon seit Jahren Tabellen mit der Maus zusammenklicken und das Ausgabeformat mit graphischen Interaktionen zusammenstellen, um daraus entsprechende Abfrageskripte mit SELECT-Anweisungen generieren zu lassen).

                Aber ob so etwas letztlich interpretiert oder kompiliert wird, halte ich für völlig unwichtig.
                Ein intelligentes "make" ist bereits in vielen PC-Entwicklungsumgebungen (z. B. Borland) enthalten; der compile-link-go-Mechanismus wird vor dem Programmierer mehr und mehr verborgen werden, weil dieser beim Anklicken des Menü-Eintrags "Programm laufen lassen" gar nicht mitbekommen muß, daß diese Funktion erst mal via "make" prüft, ob sie etwas übersetzen muß oder nicht.
                Wichtig ist, wie es für den Benutzer aussieht - nicht, wie es intern realisiert wird.

                1. Hi Michael und Andreas!

                  Gründe:

                  • Skripte lassen sich schnell entwickeln, da das compilieren und linken entfällt.

                  Ich finde, das Compilieren und Linken ist kaum mehr Arbeit als das Starten eines Scriptes. Wenn ich mir einen Batch schreibe und denn von der Befehlszeile immer wieder aufrufe, sind das dank Kommandowiederholung zwei Tastendrueck: Pfeil nach oben und Enter. Wenn ich eine Perlscript wiederholt starte, sind genau dieselben beiden Tasten zu druecken. Wenn ich ein JavaScript schreibe, muss ich einmal im Browser Reload druecken. Ich finde, da ist kein grosser Unterschied.

                  • In Skriptsprachen kann man sich zu nutze machen, daß der "Parser" (Interpreter/Übersetzer) auch zur Ausführungszeit aktiv ist und z.B. viel mehr "in Worten" programmieren (vgl. z.B. der 'eval'-Befehl in Javascript).

                  Das hat doch nichts damit zu tun, ob die Sprache interpretiert wird oder nicht!
                  Auch in einer Compilersprache könnte man eine eval-Funktion schreiben und per Bibliothek zu jedem beliebigen Programm hinzubinden. Man muß es nur tun (wollen) ...

                  Doch, es hat was damit zu tun. Klar koennte man auch fuer C ein eval schreiben. Nur muesste man da ja den ganzen C-Compiler nochmal mit in die Applikation einbauen. Da JS aber einfach nur Text interpretiert, macht es keinen Unterschied, ob der nun fest in einer Datei steht oder aus einem dynamisch zusammengesetzten String kommt. Ich glaube, das eval ist einfach ein Nebenprodukt der interpretierenden Sprachen, das man aufgrund seiner Maechtigkeit dem Scripter zur Verfuegung gestellt hat, ohne dass dafuer ein grosser Aufwand getrieben werden musste. Wie gesagt, bei einer kompilierenden Sprache kostet soetwas sehr viel, denn man muss einen (abgespeckten) Compiler mit in die EXE (or whatever) intergrieren.

                  Auch kann man z.B. Formeln auf leichteste Weise zur Laufzeit parsen lassen, so daß der Benutzer einer Anwendung z.B. statt Zahlen auch Formelausdrücke in irgendwelche Eingabefelder eingeben kann usw...

                  Auch das hat nichts mit der Programmiersprache zu tun, sondern mit dem Komfort einer Anwendung.
                  Ob ich in einem HTML-Formular JavaScript-Routinen für die Syntaxanalyse einer Formulareingabe anbiete oder nicht, ist meine Entscheidung, nicht aber eine Eigenschaft von HTML oder JavaScript.

                  Auch hier ist es eine Frage des Aufwands. Ich kann in C natuerlich einen Formelparser schreiben, wie ihn jedes vernuenftige Matheprogramm hat. Aber in JS ist er eben schon da, weil der Interpreter ihn ja selber braucht.

                  Ich teile Deine Vorhersage nur insofern, als daß in fünf Jahren wieder ganz *andere* Sprachen in Mode sein werden als heute. Aber auch heute programmiert man noch in C, was eine schon ziemlich alte Sprache ist - also werden wir unser aktuelles Perl-Wissen auch in fünf Jahren noch brauchen können.

                  Ueber die Zukunft solche Progrnosen zu stellen, wage ich lieber nicht. Nur soviel: Es ist sicher kein Zufall, dass sich C bis auf den heutigen Tag so stark behauptet hat. Es ist aber in der Tat an manchen Stellen aufgrund hoeherer Leistungen der modernen Rechner nicht mehr so notwendig wie frueher.

                  Aber ob so etwas letztlich interpretiert oder kompiliert wird, halte ich für völlig unwichtig.
                  Wichtig ist, wie es für den Benutzer aussieht - nicht, wie es intern realisiert wird.

                  Richtig.

                  Bye, Calocybe

    3. eine Programmiersprache erzeugt "auf dem Betriebssystem-Kernel selbst ablaufenden Code mit eigener interner Befehlssprache (also keine DOS-Batches...) ", d.h. es muß außer dem Betriebssystem nicht noch ein Ablaufsteuerndes Programm installiert sein, in der PC-Welt sind das dann EXE-Files oder DLLs, die von EXEs geholt werden.

      Die Idee, eine Programmiersprache dadurch zu beschreiben, daß irgendetwas in einer definierten Umgebung "ausgeführt" wird, gefällt mir ganz gut.

      Ich halte allerdings die Einschränkung auf genau *eine* der vielen möglichen Ebenen, nämlich das Betriebssystem, für zu restriktiv. Was ist denn mit Maschinensprache oder gar Microcode? In beiden wird sicherlich "programmiert" (etwa eine Addition zweier Registerinhalte durch eine Sequenz von Signalen beschrieben, die bestimmte Schaltkreise dazu bringen, entsprechend zu reagieren), und es ist auch kein Problem, dafür eine hochsprachenartige Syntax und einen Interpreter zu entwerfen (in der Tat machte man so etwas in der Theorie der Schaltwerke, jedenfalls Anfang der 80er Jahre ...).

      Eine *konkrete* Plattform halte ich schon deshalb für unbrauchbar, weil ich jede Plattform emulieren kann. Wenn C eine Sprache ist, *weil* der übersetzte Code gegen das Betriebssystem "ausgeführt" wird, ist C dann keine Sprache mehr, wenn ich ein C-Programm in einem Windows-Emulator laufen lasse, der nicht selbst ein Betriebssystem darstellt (dieses führt ja gerade das Programm "Emulator" aus!)?
      Ein Programm kann durchaus eine von mehreren Plattformen realisieren, je nachdem wie es gerade eingesetzt wird.

      Außerdem bezieht sich etwa die Diskussion über Compiler oder Interpreter ja gar nicht auf die Sprache, sondern auf die Implementierung eines Programms zur Auswertung der Sprache. Für Basic gibt es Interpreter, aber auch Compiler; für Pascal gibt es Compiler, die plattformspezifischen Code erzeugen, und solche, die abstrakten Code erzeugen, der selbst wiederum durch ein plattformspezifisches Backend weiterverarbeitet werden muß. Das hat aber nichts mit Eigenschaften der Sprache zu tun, sondern mit dem modularen Entwurf eines plattformübergreifend einsetzbaren Compiler-Frontends.

      Es gab ja mal Planungen für Rechner, deren Betriebssystem ein Java-Interpreter sein sollte (Java als Maschinensprache!) - ich weiß nicht, ob sie je gebaut worden sind. Da bekäme der Begriff "Plattformunabhängigkeit" eine ganz neue Bedeutung ... :-)

      1. Da bekäme der Begriff "Plattformunabhängigkeit" eine ganz neue Bedeutung ... :-)

        Mein virtueller Internetserver hat mir heute beim Einloggen gesagt (frei übersetzt):
        "Plattformunabhängigkeit heißt: Egal auf welchem Rechner das Programm installiert ist, es läuft nie!" :-;

  10. Zitat vom ComputerBILD:

    Computer-Chaos am 9.9.99 ?

    Computer-Experten erwarten den 9.9.99 mit Spannung. [hnlich wie bei dem Jahr-2000-Fehler knnten Computer mit dem Datum Probleme bekommen.

    Der Grund: Computerprogrammierer haben fr}her das Dateiende mit einer Reihe von Neunen gekennzeichnet.
    Springt der Computer nun auf dieses Datum, knnte er die Information falsch deuten.

    1. Ups... normalerweise sollte diese Antwort zu:
      <31434.html>
      gehören. Und nicht das mit dem programmiersprache... komisch.

      Marco

  11. Meine vorgeschlagene Definition von Programmiersprache war folgende:
    Eine Programmiersprache ist eine Kunstsprache, die dem Anwender hilft, dem Computer Algorithmen in einer dem Computer verständlichen Form zu vermitteln.

    Nicht umfassend genug (4GL, siehe anderen SubThread).

    Die Aufgabe:
    Liefere Beweise oder Gegenbeweise dafür, dass JavaScript eine Programmiersprache ist.

    Schreibe einen JavaScript-Compiler. (Mein Vorschlag: Das Copy-Kommmando. ;-)

    Das "kompilierte" JavaScript-Programm kann dann von einem (noch zu bauenden) Rechner mit der Maschinensprache JavaScript ausgeführt werden.
    "Der Bau dieses Rechners wird dem Fragesteller als Übungsaufgabe überlassen." <g>

    Widerlege oder bestätige oben genannte Definition von "Programmiersprache".

    Der unklare Punkt an der Aussage Deines Freundes ist das Wort "nur". Meint der das wie "ausschließlich" oder lediglich "herablassend"?

    ps. Er ist darüber hinaus der Meinung, japanische Schriftzeichen wären keine Schriftzeichen, da sie mit einem Pinsel gemalt werden, statt mit einem Stift geschrieben.

    Ah, und das Euro-Zeichen ist kein Schriftzeichen, weil es auf meiner Tastatur noch nicht drauf ist? ;-)

    Außerdem werden japanische Schriftzeichen selbstverständlich nicht *gemalt*, sondern *geschrieben* - das folgt ja schon aus ihrer Bezeichnung als "Schriftzeichen" ... ;-)
    Auch mit einem Pinsel kann man schreiben. (Beispielsweise den Namen Deines Freundes in den Sand eines Sandkastens ... ;-)

  12. Mann, waren das viele Beiträge. Ich hab sie alle mit riesigem Interesse gelesen.
    Jetzt kommt mein Senf:

    Def.Programmiersprache:
    "Eine Programmiersprache ist ein Wortschatz.
    Dieser Wortschatz kann mittels einer korrekten Grammatik dazu benutzt werden, ein Programm zu erzeugen."

    Soweit so gut. Jetzt die Definition für Programm:
    "Ein Programm ist die Aneinanderreihung von n-Aktionen (n>1)"

    Somit ist alles, was mit einem Befehl aufgerufen wird, und dann mehr als nur eine Aktion ausführt, ein Programm. Jede Sprache, die diesen Befehl definieren kann, ist eine Programmiersprache.

    Vielleicht ist das sogar unabhängig von einem Rechner. Vielleicht ist es auch schon das Ergebnis einer Programmiersprache, wenn die Mutter zu ihrem Kind sagt: "Ab ins Bad" und das Kind geht ins Bad, putzt sich die Zähne, wäscht sich den Hals, zieht sich den Schlafanzug an.

    Blablabla <g>

    Cu
    Cgi

    1. Def.Programmiersprache:
      "Eine Programmiersprache ist ein Wortschatz.
      Dieser Wortschatz kann mittels einer korrekten Grammatik dazu benutzt werden, ein Programm zu erzeugen."
      Soweit so gut. Jetzt die Definition für Programm:
      "Ein Programm ist die Aneinanderreihung von n-Aktionen (n>1)"

      Hm, das verlagert das Problem vermutlich nur auf eine andere Ebene. (Was ist eine Aktion?)

      Was eine "Sprache" ist, darüber gibt es allerdings Aussagen in der Theorie der Formalen Sprachen und Automaten - ach, ist das lange her ... (schwelg)

      Somit ist alles, was mit einem Befehl aufgerufen wird, und dann mehr als nur eine Aktion ausführt, ein Programm. Jede Sprache, die diesen Befehl definieren kann, ist eine Programmiersprache.

      Auch der Befehl "Legt an - zielt - Feuer!" wäre dann ein "Programm" ... und die menschliche Sprache eine Programmiersprache ... grübelgrübel ...

      Vielleicht ist das sogar unabhängig von einem Rechner. Vielleicht ist es auch schon das Ergebnis einer Programmiersprache, wenn die Mutter zu ihrem Kind sagt: "Ab ins Bad" und das Kind geht ins Bad, putzt sich die Zähne, wäscht sich den Hals, zieht sich den Schlafanzug an.

      Also *das* ist bestimmt 4GL ... wenn nicht noch mehr :-)

      1. Hi Michael!

        Auch der Befehl "Legt an - zielt - Feuer!" wäre dann ein "Programm" ... und die menschliche Sprache eine Programmiersprache ... grübelgrübel ...

        Wow! Guter Seitenhieb! Den muss ich mir merken!

        Calocybe