Diskussion:Programmiersprache/Archiv/001

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Programmiersprache/Archiv/001#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Programmiersprache/Archiv/001#Thema_1

Hello World-Programm und Standardaufgaben

Ich fänds schön, wenn zu jeder Programmiersprache ein Helloworld-Beispiel (im Artikel zur jeweiligen Sprache) gegeben wird. Abkupfern könnte man zum Beispiel von http://www.uni-karlsruhe.de/~uu9r/lang/html/lang.de.html --elian

---

vielleicht könnte man hier jeweils eine Standardaufgabe in jeder Sprache lösen.

• Hello World
• Shellsort eines Zeichenketten-Arrays
• Quadratwurzelalgorithmus
• Bewegung zweier Körper (Massen) auf dem Bildschirm
• Finde das Minimum dreier Zahlen
• Umrechnung von Einheiten in andere Einheiten (DM <-> Euro)
• Erstellung eines Kassenzettels in einem Cafe

Das Programm sollte meiner Meinung nach möglichst die Grundelemente der Sprache enthalten. Nicht supertrickreich sein. Auch dem interessierten Laien (mit Kommentar) verständlich sein. Umfang vielleicht maximal eine Seite.

Weiterer Vorschlag: die Beispielprogramme auf den Sprachenseiten. Können trotzdem nochmal separat gelinkt bzw. gelistet werden.

Im Übrigen bin ich bereit (wenns klar ist, welches wir nehmen) ein solches Programm in Pascal und/oder Delphi zu schreiben. --StefanRybo

Vielleicht sollte man für gewisse Sprachen (wie SQL, lex, bison ...) einfache sprachtypische Probleme lösen, also eine einfache Datenbankabfrage oder einen einfachen Parser. --Vulture

Ich würde die Beispielprogramme auf die Sprachenseiten nehmen, Programmiersprache ist doch schon ziemlich umfangreich, und wenn die Beispiele hier landen, muss jede einzelne Sprache für das Beispiel hierhin linken.

Ausserdem würde ich mich auf zwei oder drei Beispiele beschränken (zB Hello World, Kassenzettel und Quadratwurzel - oder so, könnte evtl. auch in ein Template für Programmiersprachen einfliessen).

Perl, Python, Oberon und C++ könnte ich mindestens ein "Hello World" beisteuern. Zis

Eigentlich sollte doch ein Link auf http://99-bottles-of-beer.ls-la.net/ reichen :-)

-- Ce 20:09, 9. Okt 2002 (CEST)

ich bin auch der meinung das ein link auf ein entsprechende seite reicht.

-- SK-Genius 21:15, 6. Mai 2004 (CEST)

SQL als Programmiersprache?

Ich möchte ein paar Zweifel anmelden zum Thema Programmiersprache.

• SQL ist eine Datenbanksprache, aber keine Programmiersprache.
• Shells können zwar Skripten ausführen, sind aber eben Shells und keine Programmiersprachen.
• In der Zeittafel taucht Linux auf, das ist genauso wenig eine Programmiersprache wie Windows.

Zustimmung oder allgemeines Kopfschütteln?

Ben-Zin

• SQL ist eine Abfragesprache, keine (universelle) Programmiersprache.
• sh kann if und goto bzw. Schleifen. Also Programmiersprache.

--Walter Koch 19:21, 6. Sep 2002 (UCT)

---

SQL ist eine Programmiersprache vierter Ordnung. [Denis]

Was bedeutet in diesem Zusammenhang vierte Ordnung? Bzw. welche Programmiersprachen gehören zur ersten, zweiten und dritten Ordnung? --HJH

1. Generation: Maschinensprachen, 2. Generation: Assemblersprachen, 3. Generation: Höhere Programmiersprachen, 4. + 5. Generation: Marketing-Hype - etwas zynisch, aber eigentlich nicht. 4. Gerenation meint normalerweise "Programmgeneratoren" wie lex (lexical analyser, Lexikalische Analyse) oder yacc (yet another compiler compiler, Parsergenerator). Aber die Einteilung ist eh nicht so wichtig (weil sehr hype-lastig ;) ) und ich bin mir deshalb wegen 4. und 5. Generation auch nicht mehr so sicher. Vor allem suggeriert das auch "besser", obwohl (stark) spezialisiert wohl treffender wäre. 1. - 3. Generation sind aber "all-purpose". Vulture 07:55, 8. Sep 2002 (UTC)

Mh. Ordnung != Generation IMHO. Allerding weiß ich auch nicht, was eine P. vierter Ordnung sein soll - googlen brachte auch nichts. Denis, klär uns auf! --Walter Koch 20:06, 9. Okt 2002 (CEST)

SQL ist eine Datenbank-Abfragesprache, aber keine Programmiersprache. Schon gar keine Sprache der vierten Generation.

Es gibt natürlich 4GL (Forth Generation Language) die mit SQL zusammenarbeitet, und eine echte prozedurale Programmiersprache darstellt.

--Arbol01 18:07, 13. Mär 2004 (CET)

SQL ist nie und nimmer ne programmiersprache. kaum gibt es ne neue sprache für den "computer" und schon wird sie als programmiersprache bezeichnet. (ich würde zu gerne mal ein sql-programm sehn :D )

und das programm ist wirklich nur aus der 3. generation (nach eurer definition)

-- SK-Genius 21:15, 6. Mai 2004 (CEST)

SQL ist keine Programmiersprache, sondern eien Abfragesprache. Die zugehörige Programmiersprache zu SQL ist PL SQL (bei Oracle).

Kategorisierung in imperativ und deklarativ

Bin ich der einzige, der die Aufteilung in Imperative Programmiersprachen, Deklarative Programmiersprachen, und Funktionale Programmiersprachen hier als Grundlage vermisst? -- Nichtich 21:02, 3. Jul 2003 (CEST)

eher die Aufteilung in imperative, deklarative und funktionale Programmierung, da viele Sprachen mehrere dieser Konzepte unterstuetzen. Aber das sollte auf jeden Fall rein. --zeno 12:36, 4. Jul 2003 (CEST)

na, Prolog gehört ganz klar zu den logischen Programmiersprachen --Pinguin.tk 00:06, 7. Mai 2004 (CEST)

---

Die Aufteilung in "imperative Programmiersprachen", "deklarative" e.t.c. ist meiner Meinung nach die einzige Möglichkeit der hinreichenden Klassifizierung. Anders ließe sich z.B. eine Sprache wie Prolog nicht einsortieren. Sie erfüllt (in der reinen Sprachdefinition) einige von Rolfs Sprachelementen nicht: keine direkte Wertzuweisung ,keine elementare Mathematik,keine Schleifen e.t.c. als prädikatenorientierte Sprache hat sie einen anderen Ansatz (deshalb wird sie auch heute noch gerne in KI-ystemen eingesetzt)

prolog ist eh was besonderes. aber variablen wertzuvweisungen und elementare mathematik besitzt die sprache. ohne diese elemente währe sie auch nur ne veraltete variante von "SQL"

-- SK-Genius 21:15, 6. Mai 2004 (CEST)

Ich finde das der ganze Artikel sehr schwer verständlich ist, denn für jemanden der nicht sehr viel versteht bedeutet das ein sehr Abstossendes Erlebnis. Wir verstehen was wir schreiben, aber ein Anderer vielleicht nicht.

abschnitt "alternativen"

Diesen Absatz verstehe ich nicht:

Alternativen

Programmiersprachen sind nicht die einzige Möglichkeit komplexe Abläufe für den Computer aufzubereiten. Andere Konzeptionen sind etwa Datenbanken und Tabellenkalkulation, oder im hardwarenahen Bereich speicherprogrammierbare Steuerungen.

MH 14:52, 5. Nov 2003 (CET)

speicherprogrammierbare steuerungen laufen mit programmen im assemblerstyl.

-- SK-Genius 21:15, 6. Mai 2004 (CEST)

Eine Tabellenkalkulation kann man ebenfalls "programmieren", indem man beispielsweise Formeln in die Felder einträgt. Diese Formeln können Bezug nehmen auf andere Felder, in denen dann entweder Formeln oder auch nur Werte stehen. Vom Konzept her entspricht das einer funktionalen Programmierung. --Lstegelitz 14:33, 10. Mai 2007 (CEST)

einordnung befunge, malbolge, zt

Wo passen die Programmiersprachen Befunge, Malbolge und ZT hin?

für Befunge gibt es sogar ein funktionierendes "Game of Life" nach Conway, und ein kastriertes Schachprogramm.

Philipp Winterberg's ZT geht weit über die Brainfucks, Cows's und OOK's hinaus.

--Arbol01 15:38, 13. Mär 2004 (CET)

Erstes Programm

Mich stört irgendwie dieses erste Programm. Ich würde meinen, wenn ich mal Algorithmus und Programm vermischen darf, daß das Sieb des Eratosthenes das erste Programm war.

Was die erste Programmiersprache ist, das ist nun wieder etwas ganz anderes. --Arbol01 12:39, 12. Okt 2004 (CEST)

4GL

Hier übriegens ein einfaches Programm in 4GL:

MAIN
  DEFINE ergebnis INTEGER,
         wert1    INTEGER,
         wert2    INTEGER
  PROMPT "n : " FOR wert1
  PROMPT "k : " FOR wert2
  CALL binomial_koeffizient(wert1,wert2) RETURNING ergebnis
  DISPLAY ergebnis
END MAIN

FUNCTION binomial_koeffizient(n,k)
  DEFINE ergebnis1 INTEGER,
         ergebnis2 INTEGER,
         n         INTEGER,
         k         INTEGER
  IF ((k = 0) AND (n >= 0)) OR ((k = n) AND (k >= 0)) THEN
    LET ergebnis1 = 1
    RETURN ergebnis1
  END IF
  IF (n > k) AND (k > 0) THEN
    CALL binomial_koeffizient(n-1,k-1) RETURNING ergebnis1
    CALL binomial_koeffizient(n-1,k)   RETURNING ergebnis2
    LET ergebnis1 = ergebnis1 + ergebnis2
    RETURN ergebnis1
  END IF
END FUNCTION

Das Programm an sich zeigt allerdings nur die Eigenschaften einer prozeduralen Programmiersprache der 3.Generation. --Arbol01 12:02, 14. Mär 2004 (CET)

Die Programmiersprache C kennt an sich keine Ein-/Ausgabe!

Normalerweise sind die Elemente einer Programmiersprache:

• Wert zuweisen/ändern an/von Variablen
• elementare Mathemtik (die 4 Grundrechenarten)
• Bedingte Verzweigung (if oder case)
• Schleifen
• Umgang mit nicht mathematischen Daten (z.B. Text)
• Kommentare

Vielleicht sollte die Seite entsprechend geändert werden rolf

Das ist natürlich Blödsinn. Eine Programmiersprache ohne Ein-/Ausgabe ist nutzlos. Die Bibliothek stdio.h gehört natürlich zum ANSI-C Standard dazu.

Mit deiner Argumentation kannst Du behaupten, das auch Pascal, Modula, Ada, C++ und Python an sich keine Ein-/Ausgabe kennen. In all diesen Sprachen sollte/muß man vor Gebrauch einer Ein-/Ausgabe eine Bibliothek deklarieren. Ich glaube intelligente C/C++ Compiler werden es automatisch ergänzen, während Modula und ADA bei fehlender Deklaration eine Fehlermeldung ausgeben werden.

--Arbol01 18:15, 13. Mär 2004 (CET)

Widerspruch: das print-Statement von Python erfordert keinen Import irgendeines Moduls; bei write bzw. writeln (Pascal) verhält es sich IIRC genauso. --Tobias 17:49, 8. Apr. 2007 (CEST)

man kann die ein- und ausgabe auch als (zitat:)"Wert zuweisen/ändern an/von Variablen" sehen. ich hab damit kein problem ;) .

-- SK-Genius 21:15, 6. Mai 2004 (CEST)

jein, I/O fällt oft unter "Wirkung" eines Befehls -- aber ohne diese "Wirkung" ist es ziemlich schwierig, ein sinnvolles Programm zu schreiben! --Pinguin.tk 23:18, 9. Jul 2004 (CEST)

---

Die Gleichsetzung "visuelle Programmierumgebung" und "IDE" ist so meiner Meinung nach nicht korrekt - als IDE kenne ich eher die Integration von Editor, Compiler/Linker und Debugger unter einer Oberfläche, eine visuelle Unterstützung zum Oberflächenentwurf ist zwar oft vorhanden, muß aber nicht sein. --hermi

Stimmt. Gleichsetzung ist inkorrekt, aber die meisten modernen IDEs unterstützen auch den GUI-Entwurf.

--zeno 18:03, 18. Mai 2003 (CEST)

Entstehungsjahr PHP = 1997?

Hallo,

wie kommt ihr auf 1997 als Datum für PHP? PHP/FI ist schliesslich schon PHP und nicht erst PHP3.

MfG

Sprachvergleich

Ich bin schon dafür, Programmiersprachen anhand von Beispielen und Anweisungen miteinander zu vergleichen. Deswegen bin ich dabei unter Benutzer:arbol01/Vergleich_(Programmiersprachen) zu Bestimmten Problemen für die unterschiedlichen Programmiersprachen Quellcodes zu erstellen. Als Beispiel für Vergleiche von Anweisungsgruppen habe ich folgenden Artikel erstellt: String_Operationen. Ich bitte um Meinungen und Anregungen. --Arbol01 21:54, 15. Mär 2004 (CET)

Finde ich so eigentlich nicht besonders interessant, da diese Sprachen alle fast das gleiche Konzept verwenden und sich nur im Syntax unterscheiden. Wesentlich interessanter fände ich einen Vergleich unterschiedlicher Stringrepräsentationen, also z. B.

• Veränderbare Zeichenketten (C, ML)
• Unveränderbare Zeichenketten (Python)
• Listen von Zeichen (Haskell)
• Copy-on-write (Java)

mit Untersuchung der Effizienz der Operationen, und Beispielen, die die Unterschiede klar machen. -- Mellum 10:07, 16. Mär 2004 (CET)

Ich muß zugeben, daß ich damit angefangen habe, übrigens einiges bevor ich von Wikipedia gehört habe, um die Gemeinsamkeiten zwischen den verschiedenen Programmiersprachen herauszustellen. Die Differenzen liegen im Detail. Ich werde mich nicht mit jeder Programmiersprache befassen können, zumal ich nicht für jede Programmiersprache einen Compiler oder Interpreterzur verfügung habe (alle Listings, die ich reistelle, habe ich selst geschrieben, und sie sind alle gelaufen).

Python steht bei mir noch auf der Liste, Forth auch. Zu Haskell fehlt mir noch ein Interpreter oder Compiler. Für Ruby auch. Ach ja, die Shellskript-Sprachen fehlen auch noch. --Arbol01 18:54, 16. Mär 2004 (CET)

Esoterische Sprachen = anspruchsvolle Scherze???

Kann man die Esoterischen Sprachen durch die Bank weg als anspruchsvolle Scherze bezeichnen? Ich bin mir da nicht so sicher. So sind Brainfuck, Ook, Moo und andere Programmiersprachen Turingkomplett und nicht selten gut durchdacht. Und Befunge und ZT gehen sogar in die zweidimensionale Ebene, und lassen Schleifen zu. Als Programmiersprachen zum Programmieren hochkomplexer Programme sind sie sicher nicht geeignet, aber als Anschauungssprachen zum programmieren einfacher Programme und dem Verstehen von Turing-Automaten sind sie sicher ganz nützlich.

Klar ist natürlich, das nicht alle dieser esoterischen brauchbar sind. Sollte man nicht zwischen den halbwegs brauchbaren Exoten, und den wirklichen Scherzen unterscheiden? --Arbol01 00:17, 9. Jul 2004 (CEST)

Erst die Theorie, dann die Paradigmen, dann die Sprachen

Der Artikel legt viel zuviel Gewicht auf die imperativen Sprachen.

Ausserdem würde ich mit der Theorie anfangen, die ja die einfachsten Aspekte einer Programmiersprache modelliert. Ich werde deswegen gleichmal $\mathbb {N}$ mit auf die Liste setzen.

--Marc van Woerkom 17:59, 1. Sep 2004 (CEST)

Möglichst keine Varianten in der Kurzübersichtstabelle

Bei den Einträgen von BlitzBasic und BlitzPlus gerade in der Zeittafel musste ich erstmal schlucken. Ich würde lieber nur den Hauptrepräsentanten einer Programmiersprache in der Zeittafel sehen. Also hier vermutlich Basic. Delphi ist auch nur ein Pascal Dialekt. Weg damit.

C# müsste man auch rausschmeissen, da es ein Java Klon ist. Java wiederum ist ein abgedooftes C++. C++ unterscheidet sich hinreichend genug von C um einen eigenen Eintrag zu rechtfertigen. Aber ich erwarte nicht wirklich Zustimmung für das Rauswerfen von C# und Java. :)

C# ist java jedenfalls sehr viel ähnlicher als java C oder C++.. die syntax ähnelt sich, aber sonst sehe ich da nicht allzuviele parallelen.. -- ∂ 23:26, 21. Sep 2004 (CEST)

--Marc van Woerkom 17:20, 4. Sep 2004 (CEST)

Ich habe die Links zu den Blitz-Basic-Varianten in der kurzen Zeittabelle gelöscht, weil

1. Marc das empfiehlt
2. Es unter BASIC eine Liste von 25 Basicdiakleten gibt und nicht klar ist, warum gerade diese wichtig sein sollen.
3. Durch das Erscheinungsdatum nach 2000 suggeriert wird, dass es sich um besonders beachtenswerte, moderne Sprachen handelt. In Tat und Wahrheit sind es Nischenprodukte, die an ihrer Stelle durchaus ihre Rechtfertigung haben, aber sicher nicht in einen allgemeinen Artikel gehören. Es gibt nämlich noch weitere solche Basicsprachen wie z.B. PureBasic.
4. Nützlich wäre sicher die Liste von Basicdialekten zu überarbeiten und prominent hinzuzulinken.

HannesH 17:07, 11. Sep 2004 (CEST)

Stimme mit der Entfernung von zu spezielllen Basicdialekten absolut überein. Java und C# würde ich aber in jedem Fall drinn lassen. --Sprezz 04:40, 12. Sep 2004 (CEST)

Danke für Eure Zustimmung. --Marc van Woerkom 18:02, 13. Sep 2004 (CEST)

ich mag listen nicht - aber einen eigenen fließtext-artikel über basicdialekte fände ich interessant. -- ∂ 23:26, 21. Sep 2004 (CEST)

Umgang mit nicht mathematischen Elementen als Elemente einer Programmiersprache?

Ist der Eintrag

• Umgang mit nicht mathematischen Elementen zum Beispiel mit Text, Bildern, Sound...

wirklich als Element einer Programmiersprache aufzufassen? Kann ja sein dass ich das falsch aufgefasst habe, aber üblich ist doch eher eine Realisierung solcher Funktionen über Zusatzbibliotheken (bzw. die Bilder/Texte/Sounds liegen bereits in einer digitalisierten Form vor wenn sie durch ein Programm genutzt werden) !? --Wizzar 02:51, 4. Dez 2004 (CET)

In objektorientierten Programmiersprachen werden Datenstrukturen und Methoden, die auf diesen Datenstrukturen operieren, in Klassen gekapselt. ... diesen Satz bitte, bitte verständlich schreiben !

Vielleicht so? In der objektorientierten Programmierung bedient man sich der sogenannten Kapselung von Daten und Logik (Code), sowie einem Zugriffsschutz vor unberechtigten bzw. ungültigen Schreib-/Leseoperationen. Im Idealfall dürfen die Daten eines Objektes einer Klasse nur von den Funktionen (Methoden) der Klasse verwendet/modifiziert werden. Dies soll die Integrität der Daten gewährleisten. --Lstegelitz 15:35, 10. Mai 2007 (CEST)

Lesenswerte-Diskusion

Ein gut geschriebener Übersichtsartikel, der gut ins Thema einführt. Keine Bilder und Literatur.

• Pro von mir. --Zahnstein 01:27, 4. Apr 2005 (CEST)
• Contra ich sehe noch ein paar inhaltliche Schwächen:
  • wo tauchen die funktionalen Programmiersprachen bei "Sie vermitteln ... genaue Angaben zu einer Kette von internen Verarbeitungsschritten" auf? Diese vermitteln alles mögliche, aber eben nicht das.
  • im zweiten Abschnitt sollte weniger die 0/1-Trivialität beleuchtet werden, viel mehr müßte herausgestellt werden, dass durch Programmiersprachen komplexe Anweisungen automatisch und viele Maschinenbefehle übersetzt werden
  • die einzelnen Abschnitte innerhalb der "Besonderen Ausprägungen" sind etwas kurz - insbesondere für die funktionalen Sprachen viel zu kurz - das müßte ein eigenes Kapitel sein.
  • Objektorientiertheit ist auch viel zu kurz
  • "Imperative Programmiersprache" sollte erläutert werden
  • die Zeittafel hat nur einen fragwürdigen Wert - interessanter wäre ein ausformulierter Text, der beschreibt, wann für welchen Zweck welche Sprache entwickelt worden ist, wo diese eingesetzt wurden (oder werden)
  • Die Tatsache, dass jedoch irgendein Programmierer irgendwann ein Programm in einer Turing-Vollständigen Programmiersprache schreiben muss, hat sich trotz aller Industrialisierung nicht geändert und ist weiterhin ein Bestandteil des Selbstverständnisses vieler Programmierer. dürfte für einen Laien komplett unverständlich sein
  • insgesamt werden im Text ein paar Dinge zwar gut erklärt, es fehlt aber noch zu viel, und der Text müßte vermutlich komplett umstrukturiert werden. Mwka 06:03, 4. Apr 2005 (CEST)
• Contra: der Artikel ist in fast jeder Hinsicht schlecht. Er vermittelt keine Intuition fuer den Unwissenden, was eine Programmiersprache ist; auch für Leute mit Vorbildung in formalen Systemen (z. B. Mathematiker/Physiker) zu dünn; für Leute, die schon grob bescheid wissen, sind die die Details unausgewogen (zu sehr auf imperative Sprachen ausgerichtet) bis falsch. Keinesfalls lesenswert. Eher ein Kandidat für "komplett neuschreiben" (siehe auch [1]; falls das mal fertig wird, würde ich es übersetzen, scheint mir recht gelungen). --Mellum 11:12, 4. Apr 2005 (CEST)
• contra: zu unverständlich... --Kurt seebauer 13:25, 4. Apr 2005 (CEST)
• contra --HaSee 17:13, 5. Apr 2005 (CEST)

Programmiersprache ist ein recht umfangreiches aber interessantes Thema, falls sich derzeit ein paar kompetente Leute noch bereit erklären, diesen Artikel lesenswert zu machen und umzuschreiben? die contra positionen sind recht hilfreich dabei. ich habe derzeit nur die einleitung bearbeitet. sollte nicht eine einteilung besprochen werden? --62.134.232.28 12:13, 16. Sep 2005 (CEST)

weblinks - links zu boards und aehnl.

momentan gibt es bei den weblinks zwei eintraege (http://www.programmiersprachen.de/, http://lambda-the-ultimate.org/) zu forum-/board-/blog-seiten. es gibt jedoch noch ungefaehr 923784569 weitere (z.b. http://www.entwickler-forum.de, http://forum.jswelt.de, http://www.softgames.de/forum/, http://www.resourcecode.de/forum.php, ...). ich bezweifle jedoch, dass die aufzaehlung all derer sinnvoll waere. andererseits sind bloss diese zwei links irgendwie "zu wenig". wie koennte man das besser gestalten? --seth 8. Jul 2005 21:19 (CEST)

lambda the ultimate ist weit, weit vorne und imho essentiell, ich kenne jedenfalls absolut nichts vergleichbares. deswegen habe ich den link reingeschrieben, auch wenn wir sonst keine blogs und foren verlinken. -- ∂ 03:38, 3. Sep 2005 (CEST)

Ich sehe keine essentielle Wichtigkeit. Das Thema wird genau genug im Artikel bzw. in den Wikibooks beschrieben. Außerdem handelt es sich um einen englischsprachigen Link, welche ja allgemein auf der deutschen Wikipedia Seite zu vermeiden sind. Wenn wirklich ein 'essentieller' Blog für dieses Thema notwendig ist, dann doch bitte einer auf deutsch. Daniel Bovensiepen 20:56, 18. Apr 2006 (CEST)

Computerprogramm = Text?

Mich stört diese Anmer kung etwas: " In Form eines Computerprogrammes (eines von einem Menschen geschriebenen Textes) vermittelt...". Ich habe neulich mal wieder in RCX-Code programmiert, wo man nicht in Textform, sondern in einer grafischen Form programmiert (Einzelne Befehle sind Blöcke, die man zu Linien verbindet, IF ist eine Gabelung, Threads sind unterschiedliche Ketten etc.). Oder die im StarCraft-Editor benutzte Programmiersprache: Die ist zwar auch ein Text, jedoch wird dieser Text nicht geschrieben, sondern entsteht, indem man auf Lücken im Text klickt und dann aus einer Auswahl wählt, was denn an dieser Stelle stehen soll). Auch wenn die dem Englischen nachempfundene Textform zum Standard gehört sollte man meiner Meinung nach nicht sagen, dass ALLE Programme von Menschen geschriebene Texte sind. Kennt eigentlich noch jemand andere Programmiersprachen, die man nicht in Textform schreibt? -- RedNifre (nicht signierter Beitrag von 80.184.172.87 (Diskussion | Beiträge) 19:35, 6. Sep. 2005 (CEST))

1. mir gefaellt die formulierung auch nicht, obwohl letztendlich auch die grafischen sprachen bloss text (assembler) generieren. die formulierung vom entsprechenden wikipedia-artikel "ein festgelegter Ablauf am Computer" gefaellt mir besser.

2. auf Programmiersprache#Visuelle_Programmierumgebungen sind weitere grafische umgebungen.

3. gibt's eigentlich regeln darueber, wo man einen _neuen_ diskussionsbeitrag platzieren darf? ich dachte man solle dafuer immer das '+' neben seite bearbeiten verwenden. aber vielleicht ist das ja gar kein muss?--seth 22:09, 6. Sep 2005 (CEST)

• boing* *ROTFL* Vorsichtig gesagt (*kicher*), da ist wohl was dran ... -- PvQ Bewertung - Portal 07:14, 21. Mär. 2007 (CET)

Nicht ganz richtig, Jenny - falls du noch hier liest. Computerprogramm = Abfolge von Befehlen an Prozessor. Der Prozessor verarbeitet Bits und Bytes. Es ist durchaus legal, grafische Programmierung mit textueller zu vergleichen. Wenngleich grafische Programmierung intern in textuelle übersetzt werden mag, wird beides letztendlich in eine Bitfolge übersetzt, die kein Text ist. Computerprogramm ist weder Text noch Grafik (die Form in der die Befehle beim Programmieren vorliegen spielt keine Rolle für das Programm, nur für die Programmierung)! Sprache wird es zwar genannt, ist jedoch nicht wirklich sinnig. Kalkül würde es besser treffen, jedoch ist das nicht mehr zu ändern ;) Alles klar? --Lupenrein 16:43, 23. Dez. 2008 (CET)

Ups! Datum übersehen. Wird hier nicht archiviert? --Lupenrein 16:44, 23. Dez. 2008 (CET)

Visuelle Programmiersprachen - Hypercard

Hallo,

wenn VisualBasic eine eigene Kategorie ist, dann sollten aber auch Vorläufer wie Hypercard erwähnt werden - das erlaubte das Anlegen von Karten, grafisches gestalten, visuelle Verknüpfung mit Aktionen sowie "Event"-Belegung mittels "on mouseup"... sowie "echte" Programmierung mit Hypertalk.

s.a. http://de.wikipedia.org/wiki/Hypercard

Götz Hoffart 16:43, 13. Sep 2005 (CEST)

Exkurs: Die einfachste Programmiersprache

aus http://de.wikipedia.org/w/index.php?title=Programmiersprache&oldid=11091351

Ich habe mal den Abschnitt "Exkurs: Die einfachste Programmiersprache" entfernt, aus zwei Gruenden:

• Die Tatsache, dass eine abzaehlbare Menge eine Surjektion von den natuerlichen Zahlen hat, ist banal und nicht hilfreich. Genausogut koennte man behaupten, die einfachste Sinfonie oder der einfachste König von Bayern sei eine natuerliche Zahl.
• Die Behauptung, dass es mehr berechenbare Funktionen gibt als berechenbare Funktionen, stimmt nicht. --Mellum 10:57, 26. Nov 2005 (CET)

der autor des abschnitts hat zwar hierBenutzer_Diskussion:Marc_van_Woerkom#.22Die_vielleicht_einfachste_Programmiersprache_der_Welt.22 noch ein erklärung zugefügt. ich muss dir recht geben dass das keine begründung ist. der wahre kern ist trotzdem da: was aber den einfachen könig von bayern von der programmiersprache unterscheidet, ist die mögliche durchnummerierung von programmtexten (das kommt im exkurs tatsächlich nicht so gut rüber). beim zweiten is offensichtlich ein berechenbar zuviel. --Archiv 15:58, 26. Nov 2005 (CET)

Diagram ist fehlerhaft

• C++ stammt nicht von Smalltalk ab
• Java stammt nicht von C++ ab (obwohl die Syntax ähnlich ist):

 http://www.cs.umd.edu/users/seanl/stuff/java-objc.html
 http://groups.google.com/group/comp.sys.newton.misc/msg/91cc2136f0252423

• Objective-C fehlt (das ist das Bindeglied zwischen Smalltalk und C)
• Eiffel fehlt ( hat Java beeinflusst, ca. 1989 erschienen)
• JavaScript hat mit Java nur den Namen (ursprünglich hieß es LiveScript und wurde nur aus Marketinggründen zu JavaScript und heißt heute eigentlich ECMA Script) und die Syntax gemein, es ist eine prototypenbasierte Sprache
• siehe auch: http://www.levenez.com/lang/history.html

IOOI 18:23, 25. Dez 2005 (CET)

diese diagramme sind eh nur eye candy. für alle angeführten punkte lässt sich ne begründung finden wiesos doch so is wie im diagramm da ja nichma pfeile angegeben sind und es sich frei interpretieren lässt. am besten man entfernts. --

• Wie sieht es eigentlich mit Python aus? Diese Sprache ist ja relativ weit verbreitet und hat interessante Eigenschaften, fehlt aber im Diagramm. Weiß jemand mehr, wie Python einzuordnen ist?

Programmiersprache (verlängert bis 3.12.)

Eine Programmiersprache ist eine künstlich geschaffene Sprache zur Darstellung von Berechnungen.

Hab da dran rumgefummelt, keine exzessiven Listen mehr. --Archiv 01:22, 26. Nov 2005 (CET)

• contra - viel zu kurz. Keine Codebeispiele, nicht erklärt, was Turing-Vollständigkeit ist, nichts über funktionale Sprachen... Das reicht noch lange nicht. --Kurt seebauer 23:00, 27. Nov 2005 (CET)

AW: halt nicht geschwätzig. unter sprachgenerationen. wurde verlinkt. bereits erfasst und verlinkt. vielleicht nochmal lesen? --Archiv 00:30, 28. Nov 2005 (CET)

hab schon gesehen, dass die Begriffe verlinkt sind. Aber so einen zentralen Artikel hätte ich doch gern etwas ausführlicher, sorry. Siehe auch [2]. --Kurt seebauer 13:20, 28. Nov 2005 (CET)

der englische rewrite artikel is nich (mehr) wirklich ne referenz, bspw. is der why-abschnitt bisschen am thema vorbei. und letztlich steht auch nicht viel mehr substantielles drin (ohne einen hier bereits vorhandenen artikel wie statische bindung zu doppeln).--Archiv

• pro:Für lesenswert reicht es meiner Meinung nach.--G 14:56, 1. Dez 2005 (CET)
• contra, aber sowas von! Der Artikel macht für mich mehr den Eindruck eines schlecht strukturierten, chaotischen Portals. Alles Wesentliche, sogar die Geschichte, so banale Sachen wie Befehlsfolge und kurze Abschnitte wie Imperative Programmiersprache wurden in andere Artikel ausgelagert. Der Rest steht in einer ziemlich zufällig erscheinenden Reihenfolge. Ich bin als Informatiker vom Fach, aber bei diesem Artikel wüßte ich nicht, wo ich mit dem Verbessern anfangen sollte. Am besten mit einer leeren Seite. --FritzG 12:47, 2. Dez 2005 (CET)

ich persönlich würde nie so flach argumentieren.. wenns wenigstens konstruktiv wäre. welche reihenfolge würde denn der informatiker bevorzugen? --62.134.233.41 18:46, 5. Dez 2005 (CET)

Eine Programmiersprache ist eine künstlich geschaffene Sprache zur Darstellung von Berechnungen. = evtl. schon durch, aber wie schafft man künstlich Sprachen? --Lupenrein 16:33, 23. Dez. 2008 (CET)

contra. Auch für mich sieht ein lesenswerter Artikel anders aus. In dem Artikel fehlt noch Struktur und wesentliche Informationen. (Wie kann man überhaupt wissen, wann so eine Lesenswert-Diskussion gestartet wird? Gibt es da nicht einen Hinweis auf der fraglichen Seite selber?? Hab den Artikel Programmiersprache unter Beobachtung, aber von einer Lesenswert-Diskussion nichts gemerkt. --Herbert Klaeren 14:03, 28. Jan. 2009 (CET)

Die Diskussion ist ja auch 3 Jahre alt ;) Lupenrein hat hier nur nochmal reingeschrieben. --Zhujik 00:36, 11. Feb. 2009 (CET)

Bild "HTML-Quelltext"

Ich bin der Meinung, es ist ungeschickt, ausgerechnet den Quelltext von HTML als Illustration eines Artikels "Programmiersprache" zu verwenden. Die Einordung von HTML als "Programmiersprache" ist bestenfalls umstritten. Ich schlage deshalb ein Schnipsel C (wegen weiter Verbreitung) oder BASIC (hat jeder schon einmal gesehen) als Nachfolger vor. (nicht signierter Beitrag von 84.146.252.132 (Diskussion) )

Das Beispiel enthält immerhin JavaScript, also schon eine Programmiersprache. Ich stimme dir aber zu, dass eine „echte“ Programmiersprache zur Illustration besser geeignet wäre. --jpp ?! 12:41, 27. Feb 2006 (CET)

Ein Snapshot von Eclipse wäre eigentlich passender (wegen der Bildunterschrift) (pikapika)

Stimme dem zu, dass HTML hier falsch ist. Einen Screenshot von Eclipse fände ich aber nicht gut, da das eher zum Thema "IDE" gehören würde und nicht zu Programmiersprache. Außerdem gibt es genug andere Leute die nicht Eclipe als IDE benutzen. Also ich wäre für ein ähnliches Textbasiertes Bild mit Syntax highliting von einer anderen Programmiersprache. Die Bildunterschrift würde ich dann dazu abändern und die Programmiersprache nennen. (GAST)

Ich habe nun einen Screenshot erstellt der die Programmiersprache Ruby zeigt. Es ist ein (meiner Meinung nach) kleiner und verständlicher Codeabschnitt. Daniel Bovensiepen

vorher sahs ästehtisch aus, jetzt ist es hässlich. (auch Gast)

Hallo Gast. Kannst du das bitte näher erläutern? Was sieht denn hässlich aus? Der Aufwand ist ja sehr gering das Aussehen anzupassen, jedoch ist die Aussage 'vorher sah es ästehtisch aus' ziemlich Inhaltslos. Wenn der Quelltext jetzt schlechter zu verstehen ist, können wir es gerne wieder ändern, jedoch bleibt der Punk bestehen, dass es sich bei HTML nicht um eine Programmiersprache handelt und die Art der Zeilenumbrüche für die Allgemeinheit den Eindruck vermitteln das Programmiersprachen unstrukturiert und unleserlich sind. Daniel Bovensiepen 17:59, 15. Apr 2006 (CEST)

muss ich dir wirklich ästhetik erklären? das bild war als symbolbild angelegt (um was es etwa geht statt details), wie das bild bei penis. und ja: html kann man auch als programmiersprache sehen. andererseits ist ruby auch viel unleserlicher als andere programmiersprachen. wenn du willst, mach doch das bild in farbe/größe/umfang/details von früher mit ruby. Gast

Nein du musst mir natürlich nicht erklären was ästhetik bedeutet. Es stellt sich nur die Frage wie dieses Wort mit der Darstellung von purem Text in Verbindung gebracht werden soll. Man kann Perl, Smalltalk oder auch Visual Basic als ästhetisch empfinden. Das sind jedoch vollkommen subjektive Ansichten die in einer Enzyklopädie nix zu suchen haben. Es geht wie du schon gesagt hast um ein Symbolbild. Und ein Quelltextauszug von HTML ist kein Symbolbild für den Artikel Programmiersprachen. Wenn du beweisen kannst das HTML Turingfähig ist, würdest du mich davon überzeugen das HTML als Programmiersprache, aufgrund seiner weiten Verbreitung, dass optimale Symbolbild für diesen Artikel darstellt. Solange jedoch HTML nur Informationen und keine Logik beschreibt wirst du die Turingfähigkeit nicht nachweisen können. Daniel Bovensiepen 20:40, 18. Apr 2006 (CEST)

Turing-fähigkeit ist laut normativen Definitionen von "Programmiersprache" keine notwendige Voraussetzung. HTML ist eine künstliche Sprache mit eindeutigen Anweisungen (ja, auch Formatangaben sind Anweisungen) an einen Computer und damit klar eine Programmiersprache, auch wenn das gern bestritten wird. - RM 10.12.06

Ruby ist ein geeignetes Beispiel für eine Programmiersprache. Python wäre auch noch günstig oder C oder Java, aber man muss ja nicht immer dasselbe sehen. Ruby ist nicht hässlich. (murphy)

Gegen Ruby habe ich ganz und gar nichts, aber das konkret gewählte Beispiel finde ich etwas unglücklich. Es mag geeignet sein, um einen Programmierer einen erste Eindruck von Ruby zu geben. Aber ist es auch geeignet, einem Nicht-Programmierer einen ersten Eindruck von Programmiersprachen zu geben? Und in Sachen Ästhetik: Ich empfinde den schwarzen Block, als den das Bild im Kontrast zur restlichen, weißen, Seite erscheint, nicht gerade als schön. Stichwort Grauwertverteilung. TillmannRendel 02:19, 14. Jul 2006 (CEST)

Auch wenn die Diskussion zwischen HTML und Programmiersprache einen Bart hat: Ob HTML auch als Programmiersprache eingeordnet werden kann ist wohl rein akademischer Natur. Da auch die Wahl der Programmiersprache als Beispiel nie alle zufriedenstellen kann und Laien mit den meisten Ausschnitten aus Programmcode sowieso nichts anfangen können, wäre es vielleicht sinnvoll Pseudocode als Beispiel aufzuführen, das nur als Anschauung dient. Alternativ wäre auch ein großes Bild mit mehreren Screenshots unterschiedlicher Sprachen denkbar. Wäre auch bereits so ein Bild zu erstellen, Anhänger dieser Idee mögen sich doch bitte melden wenn sie hier Beispiele ihrer favorisierten Programmiersprache und IDE beisteuern möchten. --Vash 15:32, 12. Dez. 2006 (CET)

"D" im Stammbaum der Programmiersprachen

Hallo Zusammen,

wenn der Stammbaum der Programmiersprachen das nächste mal überarbeitet wird, möchte ich vorschlagen die Sprache "D" etwas nachzupflegen.

Meiner Ansicht nach stammt sie nicht nur von "C" ab, sondern hauptsächlich von C++, Java und C#:

Imports von Java [1]
Templates von C++ [1]
und Delegates von C# [1]

Ein bischen C ist allerdings auch drin, z.B. "printf" [1]

Walter Bright, der Erfinder der Sprache, ist sonst für seine C++ Compiler bekannt [2]

Quellen:
[1] "Was kommt nach C++", c't-Magazin 3/2007, Seite 214 - 217
[2] www.digitalmars.com
(nicht signierter Beitrag von DracoSan (Diskussion | Beiträge) 10:03, 2. Mär. 2007 (CET))

SITEFORUM Script als Programmiersprache

Hallo, es wäre sehr nett, wenn sich Autoren finden, die sich bei der serverseitig interpretierten Programmiersprache "SITEFORUM" beteiligen könnten. Danke! --anuvito 16:53, 15. Jul. 2007 (CEST)

Kandidatur Lesenswert Januar 2007 (gescheitert)

Meiner Meinung nach inhaltlich vollständiger Artikel über ein gr0ßes und schwieriges Thema. Für Exzellenz müssten sicher noch sprachliche Details verbessert werden. --Hoast 14:36, 24. Jan. 2007 (CET)

Nie im Leben!

• Anschnitt Geschichte: Erwähnt nicht den Lambda-Kalkül, die erste turingmächtige Programmiersprache. Ebensowenig werden die außerordentlich bedeutsamen Programmiersprachen LISP und Prolog genannt. Stattdessen beschäftigt sich mehr als die Hälfte des Abschnitts mit aktuellen Modeerscheinungen.
• Abschnitt Klassifizierungen: Furchtbar. Objektorientiertheit nimmt mehr Platz ein als Imperative und Deklarative Programmierung. Alle drei Paradigmen werden miserabel erklärt. Was ist mit Multiparadigmensprachen wie Leda und Oz? Und wieso wird erst auf die verschiedenen Paradigmen eingegangen, dann kommt eine neue Überschrift "Programmierparadigmen"?

Der Artikel ist in einem katastrophalen Zustand. Es mangelt ihm an Überblicksvermögen und Einsicht in die fundamentalen Konzepte. --Phrood 23:13, 24. Jan. 2007 (CET)

• Hm, soweit ich weiß war schon die Analytic Engine turingmächtig, also ist das Lamdakalkül sicher nicht *die erste* Programmiersprache in diesem Sinn und ob esoterische Multiparadigmensprachen auch noch in den meiner Meinung nach schon sehr ausführlichen Artikel gehören? Seis drum, ich geb ein  Neutral da ich ja den Artikel vorgeschlagen habe. Wäre schön wenn jemand ein inhaltlichen Kommentar zum Artikel abgeben könnte, der auch professionell damit zu tun hat. --Hoast 00:44, 25. Jan. 2007 (CET)

• contra - den Artikel hätte ich mir komplett anders vorgestellt. Die Einleitung ist etwas abschweifend (Software-Entwicklungsprozess rausschmeißen), welche persönlichen Eigenschaften das Programmieren erfordert, ist subjektiv. Den Begriff Semiotik habe ich noch in keinem Buch über Programmiersprachen gelesen, er kommt im Artikel nicht einmal in seinem eigenen Abschnitt vor. Was ist das überhaupt? Stattdessen sollte mehr zur Semantik gesagt werden. Der Abschnitt zur Geschichte ist zu kurz. Beispiele fehlen. Die Unterscheidung und Beschreibung funktionaler, deklarativer, logischer, prozeduraler und objektorientierter Sprachen ist nicht vorhanden/wenig gelungen. Finde ich in der Form nicht bapperlwürdig. --Kurt Seebauer 01:08, 25. Jan. 2007 (CET)

•  Contra Gründe bereits genannt Michael 01:40, 27. Jan. 2007 (CET)

• Contra, siehe oben. —mnh·∇· 13:37, 27. Jan. 2007 (CET)

•  Contra dito mnh --Hufi ?! 14:00, 27. Jan. 2007 (CET)

•  Contra Angefangen, von einer Einleitung, die sich beinahe völlig am Thema vorbei drängt, über die vielen Dinge, die die Vorredner schon erwähnt haben, nur ein einziges Beispiel zum Inhalt: In den 1950er Jahren wurden in den USA die ersten drei weiter verbreiteten, praktisch eingesetzten höheren Programmiersprachen entwickelt. Welche denn? Diese drei Sprachen (Lisp, Fortan und Cobol) kurz zu umreissen, dürfte so schwierig nicht sein, aber stattdessen wird der Leser auf den ebenso schlechten Artikel Geschichte der Programmiersprachen verwiesen. Die allererste Version des Artikels erscheint mir wesentlich lesenswerter, als die jetzt vorliegende. --Jackalope 11:23, 28. Jan. 2007 (CET)

Merkwürdige Zusammenstellung

[...] und funktionale Programmiersprachen, die dafür mathematische Funktionen einsetzen.

Computerprogramme zur Darstellung von Funktionen heißen Funktionenplotter. [...]

Was haben denn bitte Funktionenplotter mit funktionalen Sprachen zu tun? Leider enthält dieser Artikel relativ viele Informationen, die nur scheinbar zusammengehören. Hat vielleicht Eliza daran mitgewirkt? TillmannRendel 01:58, 11. Apr. 2007 (CEST)

Turin-vollständig

Die Tatsache, dass jedoch irgendein Programmierer irgendwann ein Programm in einer Turing-vollständigen Programmiersprache schreiben muss, hat sich trotz aller Industrialisierung nicht geändert und ist weiterhin ein Bestandteil des Selbstverständnisses vieler Programmierer.

Jede gängige Sprache ist Turin-vollständig (siehe Turing-Vollständigkeit. Also hat ja wohl eindeutig schon mal "irgendein Programmierer" ein Programm in einer Turin-vollständigen Sprache geschrieben. --Oms 17:30, 6. Jul. 2007 (CEST)

Da niemand widerspricht habe ich den Absatz gelöscht --Oms 17:33, 10. Jul. 2007 (CEST)

Unvollständig

Im Artikel fehlt doch, daß man auch Batchdateien für programmieren kann. Können die Fachleute auch was dazu schreiben, ich denke das ict wichig! --217.230.188.177 23:51, 10. Aug. 2007 (CEST)

Meinst du, "Im Artikel fehlt doch, dass man auch mit Batchdateien für programmieren kann"? Ja, da hast du recht. Doch wie stellst du dir das vor. Das gehört doch eher nach Stapelverarbeitung. Man kann nicht jede Skriptsprache mit einem Satz der Art "X ist eine Skriptsprache mit der programmiert werden kann." im diesem Grundlagenartikel verewigen. Und dass man mit einer Skriptsprache programmieren kann, ist auch trivial und steht im Artikel drin. --Thornard, ^Diskussion, 00:59, 11. Aug. 2007 (CEST)

Delenda

Also ich bin dagegen, die zwei bisherigen Absätze aus dem Geschichtskapitel zu löschen. Sie sind eine schöne Kurzfassung des verlinkten Hauptartikels und werden durch den kurzen neuen Absatz zu sehr pauschaliert. --PeterFrankfurt 22:58, 14. Sep. 2008 (CEST)

Ich füge hier alten, toten Text ein, um den Artikel zu entlasten:

Sprachgenerationen

James Martin klassifiziert Programmiersprachen in verschiedene Generationen.^{<ref>James Martin, 1981, Development Without Programmers, ISBN 978-0-13-038943-5</ref>} Teilweise wird damit die geschichtliche Entwicklung nachgezeichnet. Vor allem ist dies jedoch ein Ansatz, die Sprachgenerationen als semantische Level zu verstehen. Damit wird der Abstraktionsgrad von der zugrunde liegenden Technik mit jeder Generation erhöht. Die 1. Generation erfordert damit genaueste Kenntnis über die Funktionsweise der zu programmierenden Maschine, während in den höheren Generationen die Beschreibung des Problems wichtiger wird. Wie es letztlich zu lösen ist, soll in den Verantwortungsbereich des Rechners überführt werden.

1. Generation: Maschinensprache sind die direkt auf einem Prozessor ausführbaren binäre Zahlencodes, die die Befehle darstellen. Die Eingabe erfolgt direkt in binärer 0-1-Form. Die direkte Programmierung in einer Maschinensprache wird heute kaum noch verwendet.

Beispiel: Es soll die Addition 3 + 4 durchgeführt werden. Der Prozessor hat für die Operation addiere den festgelegten Code 00011010. 0011 und 0100 ist die Codierung der Operanden 3 und 4 im Dualsystem. Damit weist die folgende Folge in Maschinensprache den Rechner an, die Addition auszuführen: 00011010 0011 0100.

2. Generation: Assembler ersetzen die Zahlencodes der Maschinensprache durch symbolische Bezeichner (Mnemonics). Eine Assembleranweisung wird in genau einen Maschinenbefehl umgesetzt. Der Anteil der Assemblerprogrammierung ist sehr gering.

Beispiel: Es soll die Addition 3 + 4 durchgeführt werden. Der für den Prozessor geeignete Assembler hat den Bezeichner ADD für die Operation addiere festgelegt. R0 und R1 sind die Speicherzellen in der die Operanden 3 und 4 stehen. Damit weist der folgende Befehl im Assembler den Rechner an, die Addition auszuführen: ADD R0 R1.

3. Generation: Höhere Programmiersprachen (High Level Languages) führen Konzepte wie Variablen ein, um leichter verständlichen Quelltext schreiben zu können. Sprachen der 3. Generation sind weitgehend maschinenunabhängig. Die meisten praktisch eingesetzten Programmiersprachen sind höhere Programmiersprachen. Typische Elemente solcher Programmiersprachen sind Deklarationen, Blockstruktur, Prozeduren und Unterprogramme. Heute existieren viele unterschiedliche höhere Programmiersprachen, manche sogar für Spezialanwendungen. Das eine Extrem bilden die Allrounder der Programmiersprachen (general purpose language), die auf keinen speziellen Anwendungsfall zugeschnitten sind und allgemeine Abstraktionen bieten. Auf der anderen Seite gibt es die sog. Domänenspezifischen Sprachen (Domain Specific Languages, DSL), zur Zeit intensives Forschungsgebiet, die Abstraktionen für eine bestimmten Anwendungsfall bieten. So gibt es Sprachen für die Gleissteuerung von Zugstrecken mit teilweise grafischer Programmierung, d. h. der Programmtext besteht dort aus Grafiken, die beispielsweise per Mauseingabe manipuliert werden können. Ziel einer solchen Darstellung ist, von der Textdarstellung zu abstrahieren und das Programmieren einer breiteren Anwenderbasis durch intuitive Bedienung zugänglich zu machen.

Beispiel: Es soll die Addition 3 + 4 durchgeführt werden. In der höheren Programmiersprache C wird direkt die mathematische Arithmetik für die Operation addiere unterstützt. Es ist dafür eine Variable Summe vom Datentyp int nötig. Damit weist der folgende Programmcode in C den Rechner an, die Addition auszuführen: int Summe; Summe = 3 + 4;.

Objektorientierte Sprachen sind ebenfalls Sprachen der 3. Generation. Um jedoch ihre konzeptionelle Sonderrolle zu betonen, werden sie in der Literatur oft als „OO-Generation“ bezeichnet.

4. Generation: Viertgenerationssprachen bieten einfache Sprachmittel zur Auslösung komplexer Operationen. Zumeist sind sie dabei an eine bestimmte Anwendung, wie Informationsgewinnung und Listenerzeugung gebunden.

Beispiel: Es sollen aus einer Datensammlung alle Kundendaten herausgefunden werden. Falls die Daten in einer geeigneten Datenbankanwendung erfasst sind, kann mit der Sprache SQL die Aktion folgendermaßen erreicht werden: SELECT kunden FROM datenbank. Dasselbe Ergebnis ist mit einer Hochsprache nur durch eine Beschreibung von Einzelaktionen (Öffnen von Dateien etc.) zu erzielen.

Der Begriff 4GL ist nicht exakt definierbar und wird vor allem für Marketing-Zwecke eingesetzt. Gemeinsames Hauptziel aller 4GL ist es jedoch, im Vergleich mit Drittgenerationssprachen dieselbe Funktionalität mit weniger Code zu erreichen. Der Begriff wurde in den 1980er Jahren häufig verwendet. Heute wird auch der Begriff Rapid Application Development (RAD) mit überlappender Semantik angewandt. In Drittgenerationssprachen stand die Einführung von standardisierten Kontrollstrukturen im Vordergrund. In Viertgenerationssprachen liegen zusätzlich Bausteine vorgefertigt vor, die häufig in spezialisierten Anwendungen vorkommen. Nicht mehr wie ein Problem gelöst wird steht im Vordergrund, sondern was der Rechner machen muss, um dieses Problem zu lösen. Wesentliches Merkmal der Sprachen der 4. Generation ist die Abstraktionsebene, in der das Problem formuliert wird. Verlangen Höhere Programmiersprachen noch das Programmieren von prozeduralen technischen Einzelschritten, wird in Sprachen der 4. Generation die Anforderung eher problemnah formuliert und vom System in beliebigen Umgebungen unter Nutzung der technischen Möglichkeiten zur Ausführung gebracht. Weitere Merkmale sind: integrierte Gestaltung der Nutzeroberfläche, Listenerzeugung, Datenbankzugriff.

5. Generation: (Very High Level Language, VHLL) Sprachen der 5. Generation gestatten das Beschreiben von Sachverhalten und Problemen. Sie kommen vor allem im Bereich der KI (künstliche Intelligenz) zum Einsatz. Die Wahl des Problemlösungsweges kann (entsprechend dem Sprachkonzept) dem jeweiligen System (weitgehend) überlassen werden. Logikorientierte Programmiersprachen haben ungewöhnliche Eigenschaften (Backtracking, Unifikationsalgorithmen), die sie für gewisse Arten von Problemen vorherbestimmt, die mit anderen Programmiersprachen nur sehr schwer zu lösen sind. Prolog, eine der bekanntesten logischen Programmiersprachen etwa, orientiert sich in der Beschreibung der Programme an der Prädikatenlogik. Durch den Austausch der Lösungsmethode wird ein und derselbe Programmtext (Satz von Regeln) zu einem anderen Programm und liefert andere Ergebnisse (vergl. XSLT und Expertensystem). Die Verbesserung und Spezialisierung der Lösungsmethode ist seit den 1980er Jahren ein Dauerbrenner in der Forschung auf einigen Gebieten der Künstliche Intelligenz.

Semiotik

Programmiersprachen dienen der Informationsverarbeitung. Die genauere linguistische Betrachtung dieser Aspekte ist die Aufgabe der Semiotik. Sie richtet sich deshalb in Form und Funktion als Sprache an die Struktur und Bedeutung von Information. Die äußere Form, in der sich eine Programmiersprache dem Programmierer repräsentiert, bezeichnet man als Syntax. Der Quelltext besteht aus Wörtern und Trennzeichen, ganz ähnlich zu geschriebenen natürlichen Sprachen. Es sind jedoch auch andere Repräsentationen von Programmiersprachen denkbar – wie in den logischen Programmiersprachen – eine Sammlung von Fakten und Regeln. Die Bedeutung eines speziellen Symbols in einer Programmiersprache nennt man dessen Semantik. Syntax und Semantik kann man der Spezifikation, teilweise auch der Dokumentation der Programmiersprache entnehmen. Beim Erstellen von Software reicht es – vor allem, wenn mehrere Personen beteiligt sind – oft nicht aus, nur den Quellcode zu schreiben: Es ist eine Beschreibung der einzelnen Funktionen und deren Parameter notwendig. Bei der objektorientierten Programmierung, wo auch Klassen und ihre frei anwendbaren öffentlichen Methoden eine Rolle spielen, ist deren Beschreibung für die Allgemeinheit im Falle einer Offenlegung ebenso unumgänglich.

Die Beschreibung ist normalerweise sehr technisch orientiert und beschreibt APIs, Datenstrukturen oder Algorithmen. Wichtig ist hier, dass die Dokumentation des Codes alles wichtige erfasst, jedoch trotzdem so kurz wie möglich ist. Die Sprache wird meist in der formalen Notation Backus-Naur-Form (BNF) angegeben. Eine vollständig formal semantische Spezifikation einer Programmiersprache in einem einzigen Kalkül ist gegenwärtig Forschungsgegenstand.

Humbug 23:54, 17. Okt. 2008 (CEST)

Revision nötig

M.E. ist dieser Artikel insgesamt revisionsbedürftig, zu Beginn ein Vorschlag für den Kopf:

Eine Programmiersprache ist eine Notation für Computerprogramme; sie dient sowohl dazu, diese während und nach ihrer Entwicklung (Konstruktion, Programmierung) darzustellen als auch dazu, die daraus resultierenden Programme zur Ausführung an Rechensysteme zu übermitteln. Da nur die Maschinensprache vom Rechner unmittelbar ausführbar ist, bedürfen Programme in jeder anderern Programmiersprache einer maschinellen Weiterverarbeitung (durch Übersetzung oder Interpretation); eine Programmiersprache muß also für eine maschinelle Analyse geeignet sein, was zahlreiche Einschränkungen zur Folge hat. (Bei sog. Entwurfs- oder Spezifikationssprachen verzichtet man deshalb häufig auf die Ausführbarkeit.) Die Entwicklung der Programmiersprachen hat sich seit den 1940er Jahren in Spannungsfeld von Übersetzbarkeit und Bequemlichkeit (Lesbarkeit, Knappheit, Sicherheit etc.) vollzogen. Ein weiteres Spannungsfeld besteht zwischen Universalität und Anwendungsorientierung.

Anmerkung: Notation statt Sprache schon von Wirth vorgeschlagen, Akzent auf Konstruktion statt Kommunikation. (nicht signierter Beitrag von Humbug (Diskussion | Beiträge) 00:23, 17. Sep. 2007 (CEST))

die neue einleitung ist nicht unbedingt besser. quellen fehlen, der text ist unbegründet und abkürzungen wie etc. sind kein guter stil. ich würde es revertieren aber vielleicht entwickelt es sich ja noch. (nicht signierter Beitrag von 217.230.177.88 (Diskussion | Beiträge) 02:25, 4. Okt. 2007 (CEST))

Meliorierung?

Und da dachte ich, ich bin seit über 35 Jahren in der Computerei und kenne mich aus, aber das Wort Meliorierung habe ich noch nie gehört. Googeln brachte was mit "Verbesserung", LEO übersetzte es gerade mal in anglisierte Schreibweise. Ist man sich hier sicher, dass das ein für die Einleitung Oma-tauglicher Begriff ist? Ich bin da stark am Zweifeln... --PeterFrankfurt 01:16, 29. Okt. 2008 (CET)

Interessant. Meliorierung (von lat. melius, der bessere) ist an sich eine banale sprachliche Optimierung (optimus, der beste), denn letzteres kann man ja beim besten willen nur im Marketing sagen. – Ich kenne es (von F. L. Bauer) gar nicht anders, staune nur manchmal über die heutige Terminologie. Vgl. »7.5 Meliorierung von Algorithmen mit Geflechten durch selektive Umbesetzung« in Bauer/Wössner, xiii. Als Melioration gibt es das noch in der Landwirtschaft. – Ein Abschnitt über Meliorierung folgt beizeiten.

Ist also Phrasenerkennung akzeptiert? Ich habe lange gezögert, aber letztlich nicht anderes gefunden. Phrase ist mehr in der Linguistik beheimatet, ist aber m. E. sprachlich unanstößig und hat keine entgegenstehende Bedeutung (musikalisch: phrasieren, ling.: Nominalphrase, phrase marker = Syntaxbaum). — Gruß Humbug 12:32, 29. Okt. 2008 (CET)

Die Erwähnung von "Meliorierung" und "Aufrufgraph" verwirrt an dieser Stelle nur und ist inhaltlich überflüssig. Ich habs mal gelöscht... --Herbert Klaeren 14:26, 29. Okt. 2008 (CET)

Deklarative Programmiersprachen unpopulär

"Deklarative Programmiersprachen haben keine große Popularität und sind oftmals im akademischen Bereich zu finden." Ich frage mich, ob dieser Satz haltbar ist unter dem Gesichtspunkt, dass auch JSPX eine Art Deklarativität beinhaltet und es doch immer mehr zum Einsatz kommt. Oder aber XSLT ist wohl auch nicht nur im akademischen Bereich zu finden, oder? Vielleicht sollte man diesen Satz streichen?! (nicht signierter Beitrag von Pindar (Diskussion|Beiträge) 16:23, 26. Jan. 2009)

da gebe ich dir recht, zumal "deklarativ" nicht ganz eindeutig formuliert ist. Das ist zum einen funktional (was eine weite Verbreitung hat), aber auch relational (was jetzt nicht mehr besonders en vogue ist, aber im 5th generation project ganz eminent wichtig war. --Herbert Klaeren 22:15, 26. Jan. 2009 (CET)

apropos deklarativ und Markup. Gibt es irgendwelche Definitionen, ab wann man von einer deklarativen "Markup-Programmiersprache" sprechen kann? XML ist in diesem Punkt doch ein ziemliches Zwitterformat. Einerseits Auszeichnungssprache und andererseits, im Bereich XForms beispielsweise, wird sie sogar als turing-vollständig angesehen. Gibt es hierzu Literatur? --pindar 11:30, 28. Jan. 2009 (CET)

Definition/Unterschied Programmiersprache - Skriptsprache (Interpretationssprache)

Ab wann ist denn eine Programmiersprache eine eben solche ? Ich habe im Studium gelernt, dass eine Programmiersprache ausführbaren Code erzeugt. Das macht JAVA ja aber nun mal als Beispiel nicht. Der Code muss von der VM interpretiert werden. Ähnlich verhält es sich doch mit PHP, das ist meiner Meinung nach auch keine Programmiersprache. -- 85.180.233.161 (22:11, 1. Jul 2009 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Also wie ich es kenne, ist Programmiersprache der Oberbegriff und enthält als Untermengen eben sowohl interpretierte (Skript-) als auch compilierte Sprachen. Wobei letzteres ja gar nicht unbedingt von der Sprache selbst abhängen muss, schließlich gibt es neben Basic-Interpretern auch Basic-Compiler. Und selbst für reine Skriptsprachen sind schon Compiler entwickelt worden. Und einen C-Interpreter hat es auch schon mal gegeben. - Für mich benötigt eine Programmiersprache die Mindestelemente Variablen, Anweisungen und Steuerelemente (schlecht übersetzt auch als Kontrollstrukturen bezeichnet, wie Sprünge, Schleifen, If's). Da man das mit etwas Würgerei heute sogar schon in MS-DOS-Batches hinbekommt, erfüllt sogar das schon für mich die Kriterien einer Programmiersprache. --PeterFrankfurt 02:25, 2. Jul. 2009 (CEST)

Nach meinem Verstaendniss erfordert der Begriff Programmiersprache eine gewisse Maechtigkeit, d.h. es muss mit der Sprache moeglich sein, komplexe Probleme zu loesen. Hier bietet sich der Begriff Turing-vollstaenig an. Nur Sprachen, deren Semantic diese Maechtigkeit sicherstellt sind Programmiersprachen im strengen Sinn des Begriffs.

So ist z.B. HTML keine Programmiersprache, sondern ein Dokumentenformat.

Auf welche Art und Weise die Sprache dann weiter behandelt wird, um die Programme auszufuehren, d.h. ob diese compiliert oder interpretiert werden, ist hierbei meiner Meinung nach nicht wichtig.

Die Forderung turing-vollstaendig zu sein ist allerdings sehr streng, da dann z.B. SQL keine Programmiersprache ist (die ist naemlich nich Turing-vollstaendig).

--Phillip 18:25, 10. Nov. 2009 (CET)

Hmm, das mit der Mächtigkeit und den komplexen Problemen unterschreibe ich aber nicht. Schließlich beschäftigt sich ein Großteil des heutzutage Zusammenprogrammierten oft mit extrem banalen und simplen Problemen, das aber in abstraktesten Hochsprachen, denen man den Status einer Programmiersprache bestimmt nicht absprechen kann, und die selben Probleme könnten in zwei oder drei Zeilen Skript oder Basic genauso bewältigt werden. Ich tendiere dazu, die Messlatte auf das absolute Minimum zu legen (die Grenzziehung wird sonst zu sehr subjektiv-politisch), und da gehören Schleifen und verwandte Steuerstrukturen für mich dazu. Ohne das ist es wirklich kein "Programm", und HTML fällt damit auch bei mir raus. --PeterFrankfurt 01:16, 11. Nov. 2009 (CET)

geschichte

liest sich wie ein vorlesungsskript. für mich als laien ohne zusätzliche weitreichende recherche vollkommen sinnlos. 87.243.151.162 (02:45, 20. Mai 2010 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Schreib es um (Es ist ein Wiki!). Oder mache konkrete Aussagen wo der Text sinnlos ist, dann können wir gemeinsam gerne dran arbeiten. Aber so ist dein Beitrag ohne zusätzliche und weitreichende Recherche vollkommen sinnlos. --Das Ed 03:12, 20. Mai 2010 (CEST)

Verwendungshäufigkeit der jeweiligen Sprachen

...fehlt hier noch. Ist auch in der engl Version des Artikel enthalten! -- 138.246.7.9 18:43, 11. Aug. 2010 (CEST)

ja, aber glaubhaft sind solche Angaben in der Regel nicht. --Herbert Klaeren 19:51, 11. Aug. 2010 (CEST)

Ueberarbeiten, viel Spass

Ich hatte mir mal vor sehr, sehr langer Zeit den Scherz erlaubt und diesen Artikel bis zur Unkenntlichkeit editiert, seitdem ist er nicht nur unter Freunden ein Running Gag. Ich hoffe niemand nimmt die Informationen zu ernst die hier dargestellt werden, sucht euch lieber ein gutes Buch zum Thema. -- Dixon (Name war schon belegt, sry), 11/11/2009 (nicht signierter Beitrag von 141.209.40.141 (Diskussion | Beiträge) 01:51, 12. Nov. 2009 (CET))

Da ist jemand auch noch stolz, eine Artikelbeschreibungen bewusst kaputt gemacht zu machen. Es gibt schon seltsame Zeitgenossen. Zumindest hättest Du auf ein entspechendes Buch verweisen können.
Allerdings hast Du Recht: Der Artikel ist nicht gerade das 'Gelbe vom Ein' - weniger wäre mehr. --VÖRBY 22:07, 3. Sep. 2010 (CEST)

Schlechter Artikel

So schlecht. Kaum zu fassen. Ich versteh nix. Wo sind denn die Nerds? (nicht signierter Beitrag von 141.35.20.90 (Diskussion | Beiträge) 15:32, 25. Apr. 2009 (CEST))

Programmierparadigmen u.a.

Dieses Kapitel und vor allem die ausführlichen Beschreibungen gehören nicht HIERHIN. Besser wäre, diese Zusammenhänge hier nur kurz zu erwähnen und ansonsten nach Programmierparadigma zu verlinken.--VÖRBY 17:18, 20. Apr. 2011 (CEST)

Einleitung umgeschrieben; Paradigmen dienen nicht dazu, PrSpr zu gliedern, sondern PrSpr können (u.a.) nach diesen Paradigmen eingeteilt werden. Einwand damit z.T. erledigt.--VÖRBY 09:49, 21. Apr. 2011 (CEST)

Gleiches gilt für das Kapitel 'Übersetzer': Kurzer Text genügt (ist mehrfach vorhanden), dann Link auf Compiler.
Ob viele WP-Leser die Ausführungen unter 'Typsystem' so suchen oder erwarten, will ich bezweifeln. Mindestens viel zu detailliert!
Ja, ÜBERARBEITEN ist dringend fällig; ist aber nicht mein Spezialthema.--VÖRBY 20:11, 20. Apr. 2011 (CEST)

Computer kann Daten nicht von Befehlen unterscheiden

Dieser Abschnitt kann archiviert werden. VÖRBY 09:06, 22. Sep. 2011 (CEST)

Zitat aus dem Abschnitt 'Imperative Programmiersprachen': ...unterschieden in Befehle und Daten. Dies ist nicht unbedingt notwendig, da ein Computer diese Strukturen prinzipiell nicht unterscheiden kann.
Wieso kann ein Computer das nicht unterscheiden? Und wieso ist das nicht notwendig? Der Rechner führt doch wohl nur Befehle aus, also muss er diese auch identifizieren, d.h. von Daten unterscheiden können. Und dass man Daten und Befehlt braucht, halte ich schon für notwendig. Ich denke, dass mit dieser Aussage etwas anderes gemeint ist, das sollte man dann auch anders schreiben. --VÖRBY 10:19, 21. Sep. 2011 (CEST)

Ehrlich gesagt verstehe ich schon nicht, worauf sich das "sie" im Satzanfang "Sie werden unterschieden in ..." bezieht. Werden die Anweisungen unterschieden oder die Ergebnisse? Macht für mich beides wenig Sinn. Was immer mit der Unterscheidung gemeint ist, es ist im Kapitel "Programmierparadigma" jedenfalls völlig fehl am Platz. --Zahnradzacken 16:31, 21. Sep. 2011 (CEST)

Ich hab die Sache mit den Daten rausgekürzt und den Abschnitt etwas umgeschrieben.--VÖRBY 17:59, 21. Sep. 2011 (CEST)

1. Die in der Überschrift genannte Aussage ist schon korrekt.
2. Allerdings hatte sie an dieser Stelle nichts zu suchen und verwirrte den sich erst informierenden Leser mehr, als dass sie irgendwem geholfen hatte.
3. Die Streichung und Straffung war also völlig okay.
4. Mir gefiel schon nicht, dass „der Computer … unterscheidet“ – ein Computer ist kein handelndes Subjekt; das wäre der Mensch. Es hätte heißen müssen „… können prinzipiell nicht unterschieden werden“.
5. In der Sache:
   1. Es ist eine uralte und bei manchen Leuten never-ending story.
   2. Die Unterscheidung von „Befehl/Programm“ und „Daten“ ist völlig willkürlich und rein pragmatisch; eine prinzipielle Unterscheidungsmöglichkeit gibt es nicht, nur Konvention.
   3. Jedes Programm ist auch als Datenrepräsentation vorhanden, und jede halbwegs (formal) strukturierte Datenansammlung ließe sich auch als ein Programm in einer kuriosen Programmiersprache auffassen.
   4. Beispiele:
      • Jedes Programm hat auch eine Datengestalt, als Quellcode, Bytecode, Maschinencode, Kernspeicherabbild. Diesen ist irgendwann nicht mehr anzusehen, ob es „Daten“ oder „Befehle“ sein sollen.
      • Eine PDF-Datei, oder Postscript oder PCL, ließe sich als ein Programm verstehen, mit dem ein Drucker gesteuert wird. Das macht man aber üblicherweise nicht, sonst bekommt man Haue.
      • Wer noch im guten alten LISP schreibt, gewöhnt sich diese Unterscheidung schnell ab; es gibt sie dort schlicht nicht.

Schönen Abend --PerfektesChaos 18:57, 21. Sep. 2011 (CEST)

---

Ich habe dieses Diskussionskapitel auf ERLEDIGT gesetzt. Dass der 'Computer' (was immer das auch ist) Befehle und Daten nicht unterscheiden kann (auch nicht wenn man 'prinzipiell' sagt), halte ich nach wie vor für falsch, weil für Millionen von Programmen bewiesen ist, dass die 'Computer' Befehle und Daten wohl unterscheiden können. Wie gesagt: Man wollte wohl etwas anderes ausdrücken, z.B. dass im Arbeitsspeicher Befehle und Daten grundsätzlich nicht unterschieden werden, aber das gehört nicht hierher - auch nicht, dass Programme auch in Daten-Form existieren. Grüße von --VÖRBY 09:06, 22. Sep. 2011 (CEST)

Nur zu Deinem Verständnis: Der Prozessor liest nur nackte Bytes aus dem Speicher. Herkömmlicherweise ist dabei nicht vermerkt, ob es sich um Daten oder Befehle handelt (neuerdings geht das auch, aber mehr zu Sicherheitszwecken, vor allem hinsichtlich Malwareschutz, weniger gegen Programmfehlern). D. h. wenn sich ein Programm verläuft, weil es über einen zerschossenen Pointer an einer falschen Stelle im Speicher landet und sich dort mitten in einem Datenarray wiederfindet, wird der Prozessor versuchen, diese Datenbytes als Befehle zu interpretieren und abzuarbeiten, er kann diese fehlerhafte Situation nicht erkennen und wird in der Regel Chaos anrichten, der Rechner stürzt ab. --PeterFrankfurt 02:18, 23. Sep. 2011 (CEST)

Danke für die Aufklärung.  ;-) Aber wenn gesagt wird, "der Computer ..." (könne (!) das nicht unterscheiden), so stimmt das einfach nicht; denn zum Computer gehört mehr als nur der ("dumme") Prozessor. Und das, was darüber liegt (i.W. das BS), unterscheidet beide Arten - sonst wäre ja eine korrekte Verarbeitung nicht möglich. Ich denke aber, damit können wir es nun belassen. Grüße von --VÖRBY 09:05, 23. Sep. 2011 (CEST)

Nein, nein, nein. Das Betriebssystem hilft uns eben nicht mehr, wenn mal was schiefgeht! Wenn ein C-Programmierer einen Pointer nicht richtig initialisiert oder ihn aus Versehen überschreibt und das Programm dann in die Wildnis läuft, dann läuft es dort hin, egal, ob es sollte oder nicht. Das OS hindert es jedenfalls nicht daran. Hast Du noch nie einen BSOD gesehen? Genau das passiert dann im besten Fall, im schlechteren merkt das OS es nicht und arbeitet womöglich mit falschen Daten oder einem eingeschleusten Virus weiter, oder vorher sind schon solche Unglücke passiert, bevor der BSOD erscheint. --PeterFrankfurt 01:51, 24. Sep. 2011 (CEST)

Es ist ein Unterschied, ob solche "Unglücke manchmal passieren" oder zu behaupten, der Computer (das sehe ich als "System") KÖNNE (das ist eine absolute Aussage) Befehle nicht von Daten unterscheiden. --VÖRBY 08:56, 24. Sep. 2011 (CEST)

Wir sind in der Wissenschaft. Und da gilt: Nennt man EIN Gegenbeispiel, ist eine (hier Deine) Theorie versenkt. Es mag nur manchmal passieren, aber es passiert. --PeterFrankfurt 01:01, 25. Sep. 2011 (CEST)

Überarbeiten

Da muss ich der nicht-IP hier zustimmen. Ein riesen Wirrwarr an Links und Fließtext ohne Absatz und Ende.

• Übersicht gibt keine Übersicht, darin soll ein Panorama enthalten sein? Eine Übersicht in der Übersicht und damit es einfacher wird noch ein Beispiel :/
• Artikel besitzt keine innere Ordnung, was macht die Geschichte zwischen "implementierung" und "Klassifizierung"?? Was macht das das übersichtsBild der Programmiersprachengeschichte bei den "Ergänzungen" ?
• Wieso wird so extrem und kompliziert auf Typsysteme eingegangen? Der Abschnitt ist länger als der entsprechende Artikel Typsystem PS: Der wartet auch seit langem auf Überarbeitung...
• tausend Kleinigkeiten .... "siehe auch" Codegenerator, wieso? Wieso nicht siehe Syntaktischer Zucker ?
• Zitat: In der Rückschau kann man die bisherige Entwicklung der Programmiersprachen in Generationen einteilen, siehe das eigene Unterkapitel weiter unten. So ein Kapitel gibt es nicht, nicht nur das Selbtverweise nicht gut gewartet werden können, hier es gibt nicht mal einen! ala siehe unten - da wirst du es schon irgendwo finden
• lohnt nicht mehr aufzuzählen, hier ist fast nichts OMA-tauglich, das verstehn die meisten Schüler und Studenten auch nicht...

Grüße --WissensDürster 19:46, 25. Jun. 2009 (CEST)

Direkt ganz am Anfang, müsste es heißen, in einen "KONKRETEN" und nicht "abstrakten" Quellcode. Wäre er abstrakt, wäre er schwerer zu verstehen und somit logisch falsch. Und das auch noch direkt am Anfang eines Textes... Aber besser am Anfang, als mittendrin, so muss ich mir nämlich den Rest nicht durchlesen. (nicht signierter Beitrag von 143.93.128.128 (Diskussion) 14:56, 19. Jan. 2012 (CET))

1. Bitte nicht die Beiträge Anderer manipulieren.
2. Bitte überdenken, was Abstraktion bedeutet, und Kritik dann neu formulieren. Eventuell noch nachlesen, was logisch falsch heißt.

--Zahnradzacken 17:19, 19. Jan. 2012 (CET)

verknuepfung von sprachen

Einmal von der Unübersichtlichkeit abgesehen fehlt mir hier noch die Thematik wie man Programmiersprachen verknüpfen /miteinander arbeiten lassen kann. (Möglichkeiten einfach aufgezählt und Erklärung in 5 Sätzen) (nicht signierter Beitrag von 129.13.251.76 (Diskussion | Beiträge) 09:53, 10. Jan. 2010 (CET))

eine solche „Verknüpfung von Sprachen“ kann nicht Gegenstand dieses Artikels sein. --Herbert Klaeren 15:30, 19. Jan. 2012 (CET)

IP meint wohl Einbindung von „nativem Code“. Das ist auch teilweise offizieller Bestandteil der Syntax von Programmiersprachen und eine Erwähnung an passender Stelle wäre angemessen.

Die WP scheint zurzeit hinsichtlich NCI ohnehin mager aufgestellt. Die Weiterleitung Nativer Code führt direkt in die Maschinensprache – ja, kann man so sehen, war früher mal die einzige Anwendung; aber inzwischen verwendet man diesen Ausdruck auch, wenn es etwa von Java nach C geht (Java Native Interface). Aufrufkonvention#Pascal etc. müsste dafür irgendwo noch besser beleuchtet werden. Dass Softwarepakete inzwischen recht häufig hybrid programmiert sind, liegt zum einen an ihrer Entstehungsgeschichte, zum anderen konventionell an der Steigerung der Performance wie auch an der Nutzung der Plattform. Gebräuchlich ist beispielsweise auch Fortran↔C Gehüpfe. Hybridsprache wäre wieder was anderes.

--PerfektesChaos 18:36, 19. Jan. 2012 (CET)

Struktur

Der Artikel ist nicht strukturiert.

Ich würde folgenden Aufbau vorschlagen:

• Programmiersprachen Übersicht

 - Maschinencode (Binärcode)
 - Compilercode (z.B. Assembler, C,C++)
 - Interpretercode (C#, Java)
 - Scriptsprachen (z.B. VB-Script) 
 - Datenbank Sprachen (SQL)

• Befehle und Daten
• Vererbung
• Objektorientierung
• Geschichte

STEP7 ist eine Plattform, die viele elektrotechnische IO-Programmiersprachen unterstützt, z.B. AWL, KOP, FUP (AWL ist wie Assempler, KOP und FUP graphisch, kann man also so auch nicht stehen lassen) Die Objektorientierung ist eine Eigenschaft von Programmiersprachen und gab es implizit schon immer als Lösung, ich hab auch in Assembler objektorientierte Programme geschrieben. Es wäre ganz net eine zeitliche Achse zu haben, um zu sehen wann die Objektorientierung in die Sprachen Einzug fand. Als Paradigmenwechsel, würde ich die CLR aufführen, denn mit der CLR ist ein Zwischencode entstanden, der aus unterschiedlichen Programmiersprachen erzeugt wird. Man redet dabei auch von Managed Code und Assemblies. Begriffe, die allgemeingültig einer Programmiersprache zugeordnet werden können sind Befehle, Daten, und bedingt Objektorientierung und Vererbung .

--Niemand (Diskussion) 11:44, 18. Mär. 2012 (CET)

 Kontra

Die vorgeschlagene Gliederung ist leider nicht weiterführend.

• "Maschinencode (Binärcode)" gilt gemeinhin nicht als eine Programmiersprache; Menschenwürde beginnt mit dem Assembler. Die Zuse-Zeit und Jacquard-Webstühle mal ausgenommen.
• "Compilercode" scheint TF; eine gleichrangige Einordnung von Assembler und C++ hat wohl einige Jahrzehnte an Entwicklung zur höheren Programmiersprache verschlafen.
• Was eine „Skriptsprache“ sein soll, weiß niemand. Irgendwas zur Steuerung eines Anwendungsprogramms, Programmiersprache light oder sonstwas. Kann auch "objektorientiert" sein; zumindestens ansatzweise. Der Begriff ist unbrauchbar für eine Kategorisierung.
• Ob es zu einer Sprache auch einen Zwischencode (wohl mit „Interpretercode“ [TF] gemeint) gibt, ist Sache der weiteren Verarbeitung und hat keinerlei Einfluss auf die Sprache selbst.
• Ob SQL eine Programmiersprache sei, wäre stark zu bezweifeln. Zur besseren Auffindbarkeit ist sie in der Liste von Programmiersprachen aufgeführt; das mag angehen.

VG --PerfektesChaos 23:02, 18. Mär. 2012 (CET)

 Pro

• Meines Wissens nach wurden anfangs die Computer mit Lochkarten programmiert, in Maschinencode. Mann kann jetzt darüber streiten ob es noch zu Programmiersprachen zählt. Mann könnte es ja dann aus dem Kapitel in die Einleitung übernehmen.
• Assembler und C wird beides von Compilern übersetzt.
• Mit C++ kamen dann neue Sprachelemente der Objekt-Orientierung. Man konnte dann z.B. die Operatoren erweitern auf Vektoren oder Matrizen, etc...
• Skriptsprachen sind Programmiersprachen.
• SQL ist eine Datenbanksprache, die mittlerweile mit Interpretersprachen angereichert wird. (z.B. C# in MS-SQL). Auch da kann man jetzt darüber streiten, ob die Urform auch als Programmiersprache gilt.

Mit einem strukturellen Aufbau könnte man meines Erachtens schön die Entwicklung aufzeigen, die man dann auf einem Zeitstrahl noch verdeutlichen könnte.

LG --Niemand (Diskussion) 10:13, 22. Mär. 2012 (CET)

Schaut mal in das Buch von Metropolis „A History of Computing in the 20th Century“ (oder ähnlich) und in die beiden Tagungsbände „History of Programming Languages“. Erste Computer wurden zumeist „mechanisch“ programmiert, ohne jeden Begriff von Programmiersprache, etwa durch das Ziehen von Strippen (ENIAC) oder durch das Abtasten von Löchern in einem Kinofilm (Zuse Z1). Assemblersprachen waren die erste Entwicklung, die man getrost als „Sprachen“ bezeichnen konnte. Sie werden übrigens nicht von Compilern übersetzt, sondern von - wie der Name sagt - Assemblern. Es ergibt überhaupt keinen Sinn „Compilersprachen“ und „Interpretersprachen“ zu unterscheiden, denn praktisch jede Sprache lässt sich je nach Wunsch von Compilern oder Interpretern behandeln, die Frage ist hier nur, was normalerweise geschieht. Es gibt Sprachen, die während der Entwicklung eines Programms gerne mit Interpretern behandelt werden, dann aber für die Produktionsversion doch kompiliert werden. Ein kompiliertes Programm ist 10- bis 100-mal schneller als ein interpretiertes. Ob es einen Sinn ergibt, Skriptsprachen gesondert zu betrachten, bezweifle ich. Die Besonderheit von Skriptsprachen liegt wohl nur darin, dass sie dazu verwendet werden, irgendein System „fernzusteuern“ (Betriebssystem, Webserver, Photobearbeitung, Datenbank...) Damit haben Skriptsprachen eine gewisse Nähe zu DSLs (Domänenspezifische Sprache), die aber in diesem Artikel auch nicht vorkommen. Und, wie PerfektesChaos schon richtig bemerkt, ist es überhaupt nicht von Bedeutung, ob für die Implementierung einer (kompilierten) Sprache auch noch ein (interpretierter) Zwischencode wie bei Smalltalk, Java, C# verwendet wird, denn die Interpretierung des Zwischencodes wird gerne auch durch Just-in-time-Kompilierung vermieden, die wieder einen Geschwindigkeitsvorteil bringt. --Herbert Klaeren (Diskussion) 09:53, 23. Mär. 2012 (CET)

Naja, ich denke, dass es schon wichtig wäre im Artikel die Evolution von Programmiersprachen zu erkennen. Es macht einen Unterschied, wenn durch die CLR eine Ansammlung von Programmiersprachen aufeinander abbildbar werden. Ich denke, dass zwischen „Compilersprachen“ und „Interpretersprachen“ auch ein signifikanter Unterschied besteht. Zumindest würde ich den Unterschied zwischen Reptil und Säugetier als evolutionären Schritt erkennen.

--Niemand (Diskussion) 09:48, 1. Apr. 2012 (CEST)

Die Evolution versucht der Abschnitt Programmiersprache #Geschichte und sein Unterabschnitt Sprachgenerationen zu verdeutlichen, dazu der Artikel Geschichte der Programmiersprachen. Es wäre hingegen reine TF, ein neuartiges Klassifizierungssystem wie vorgeschlagen aufzudrücken, weil dies eine umfassende Auflistung aller Sprachen bedeuten würde und es sehr viele Sonderfälle gibt, die in keine dieser Kategorisierungen eindeutig hineinpassen – zumal die Bezeichnungen auch keine saubere Abgrenzung zulassen. Dies würde Niemand helfen. (Übrigens ist nicht nur diese Einteilung der Sprachen nicht möglich; auch die Unterscheidung zwischen „Befehlen“ und „Daten“ ist rein willkürlich und hängt von der Sichtweise des Betrachters ab; tatsächlich ist es etwa in LISP das Gleiche.) Kein Aprilscherz --PerfektesChaos 12:38, 1. Apr. 2012 (CEST)

Interpretersprachen - Compilersprachen, gibt es diesen Unterschied tatsächlich? Basic wurde in der Anfangszeit interpretiert weil die Resourcen zum Kompilieren schlicht nicht vorhanden waren und die Kompilierzeiten häufig die Laufzeit des Interpreters weit übertrafen, insbesondere während der Entwicklungsphase. Aber auch damals gab es schon Basic Compiler, allerdings erforderte bspw. der Petspeed ein Doppel-Floppylaufwerk und 32k RAM - damals groß und teuer und viel Zeit. Umgekehrt gibt es auch heute noch Interpreter für C und sogar C++. Es ist m.E. keine Eigenschaft der Sprache ob sie kompiliert oder interpretiert wird. --84.57.92.73 16:30, 25. Apr. 2012 (CEST)Robert

Sehe ich ähnlich. Bestes Beispiel ist Java, was unter Linux mit GCC problemlos compiliert werden kann. --P.C. ✉ 16:35, 25. Apr. 2012 (CEST)

Den behaupteten „signifikanten Unterschied zwischen ‚Compilersprachen‘ und ‚Interpretersprachen‘“ gibt es auch nicht. Weder gibt es überhaupt eine Definition zu ‚Interpretersprache‘, noch ist die im Beispiel gegebene Einordnung von Java oder C# als Interpretersprache zutreffend.

Geschichtlich wurde vorstehend bereits richtig erwähnt: Im letzten Jahrhundert hatten einige Sprachen als „Skriptsprache“, „Kommandosprache“ etc. angefangen. Sie wurden zunächst nur zeilenweise (manuell) in eine Kommandozeile, Shell usw. eingegeben; die Kommandos werden sofort ausgeführt. Die Ausführung übernimmt der Interpreter.

Jede ‚Interpretersprache‘ lässt sich aber auch zunächst in irgendeiner Weise kompilieren, ggf. linken oder laden, und dann erst ausführen.

‚Interpretersprache‘ ist also keine Klassifizierung von Sprachen, sondern eine Eigenschaft bestimmter Sprachen – dass eine solche schrittweise Verarbeitung möglich ist.

• Wobei als Vermächtnis die Eigenschaft mancher Sprachen bleibt, dass symbolische Elemente (Variablen, Funktionen) erst dann auftreten dürfen, nachdem sie zuvor physisch im Quelltext definiert worden waren. Bei der Kompilierung ist das egal; hier reicht es, sie noch nicht einmal zum Abschluss der Kompilierung, sondern erst beim Linken und notfalls erst zur Laufzeit aufzutreiben.
• Die angeführten Beispiele (C#, Java) sind nun gerade keine ‚Interpretersprachen‘. Was die kühne Eingangsbehauptung gemeint hatte, war die gebräuchliche Erzeugung eines plattformunabhängigen Zwischencode. Ob dieser generiert wird oder nicht, ist aber überhaupt keine Eigenschaft der Sprache selbst; es ist auch grundsätzlich bei allen Sprachen möglich.
• Klassische ‚Interpretersprache‘ wäre die Steuerung einer CNC-Maschine oder eines Betriebssystems (bash, REXX oder CMD). Ich kann die Wirkung auf die Maschine sofort zeilenweise erfolgen und sogar sichtbar werden lassen, oder aber den unausgeführten Code erstmal sammeln und später in aufbereiteter Form lostreten.

Ich denke, wir haben uns hier genügend mit dem eigenwilligen Vorschlag zur Neuaufteilung der Sprachenwelt beschäftigt. --PerfektesChaos 10:42, 27. Apr. 2012 (CEST)

Entwicklungslinien in der Programmiersprachenentwicklung

Das Bild ist fehlerhaft (insbesondere die C++ -Linie). Korrekteres Diagramm wäre http://de.wikipedia.org/w/index.php?title=Datei:Historie.png&filetimestamp=20060325205127 (nicht signierter Beitrag von Bushmann (Diskussion | Beiträge) 13:20, 21. Apr. 2010 (CEST))

guter Hinweis, habe ich erst viel zu spät gesehen. Da waren wirklich sehr viele Fehler in dieser Grafik, ich habe sie jetzt entfernt. --Herbert Klaeren 15:44, 16. Jan. 2012 (CET)

In diesem korrekterem Diagramm fehlt Assembler (Mnenomics). Ist zwar keine Hochsprache und sollte auch nicht mit seinen gefühlten 3.000.000 Dialekten vertreten sein, war aber einer der Grundsteine. -- Mha1993 15:58, 8. Feb. 2012 (CET)

Hallo zusammen, aktuell findet sich gar keine Grafik mehr im Artikel - was ich als Mangel empfinde. Herbert Klaeren, wenn du sagst, da seien viele Fehler drin; welche Quelle hast du dafür? Kann man die nicht verlinken? Oder evtl. die WP-Grafik Historie.png wenigstens bei den Weblinks einstellen?--VÖRBY (Diskussion) 12:58, 16. Jun. 2012 (CEST)

es gibt eine sehr gute und auch sachlich richtige Grafik in dem Tagungsband "History of Programming Languages", aber die können wir hier nicht einstellen, da wir sonst Urheberrechte verletzen. --Herbert Klaeren (Diskussion) 17:24, 16. Jun. 2012 (CEST)

Dazu gibt es keinen Weblink? Was spricht dagegen, die o.g. Grafik zu verlinken? --VÖRBY (Diskussion) 19:05, 16. Jun. 2012 (CEST).

Ergänzung: Oder die alte wieder, dennn ich denke, eine nicht ganz korrekte Grafik ist besser als keine; vielleicht mit einer Zusatzbemerkung, schließlich sind historische Zusammenhänge häufig nur 'diffus' nachvollziehbar. --VÖRBY (Diskussion) 09:04, 17. Jun. 2012 (CEST)

Verwirrung Imperativ Deklarativ

"Den genau umgekehrten Ansatz verfolgen die deklarativen Programmiersprachen."

Ada ist lt. Tabelle beides? These und Antithese?

und sollte es nicht korrekterweise deklarierend heißen. Es gibt ja deklarierende Variable, Funktion, Klasse, Zuweisung, auch Sprache. Ist das Kunstwort nicht unnötig? (nicht signierter Beitrag von 80.141.234.140 (Diskussion) 21:46, 26. Apr. 2012 (CEST))

1. „deklarativ“ ist nun mal ein seit über einem halben Jahrhundert eingeführter Fachbegriff; die WP hat das Weltwissen zu beschreiben und nicht umzuwursteln.
   • Im Übrigen steht das verpönte „Kunstwort“ als allgemeinsprachlich im Duden; wäre mal interessant, ob es das vielleicht schon vor 100 Jahren gab.
     • [3] Also 1863 war es schon in Gebrauch. --Zahnradzacken (Diskussion) 13:29, 27. Apr. 2012 (CEST)
   • Nebenbei gibt es auch keine „deklarierende Variable“ etc., sondern eine „bereits deklarierte Variable“ oder eine „die toString-Funktion deklarierende Klasse“. Wobei Typdefinitionen zu den deklarativen Anweisungen im Gegensatz zu ausführbaren (operationalen) Anweisungen gehören, die man (hier unüblich) auch imperativ nennen könnte.
2. Der Einwand, „deklarativ“ auf Ada anzuwenden sei widersprüchlich, ist allerdings relativ schlüssig.
   • Zwar heißt es unter der Tabelle im Artikel, „Eine Programmiersprache kann jedoch auch mehreren Paradigmen gehorchen“ – jedoch trifft das auf diese Kombination nur schwer zu.
   • Ich habe mal (relativ wenig) in Ada geschrieben und würde den Quellcode als rein imperativ auffassen, soweit ich mich erinnern kann.
   • Den deklarativen Ansatz verfolgt auch weniger die Sprache selbst als eher die mitgelieferte Entwicklungs- und Entwurfsmethodik. Sie war für den Spaghetticode der 1980er Jahre recht neu, und ursprünglich ein Schwerpunkt bei der Einführung der Sprache gewesen.
   • Die in Deklarative Programmierung getroffene Feststellung „Der Lösungsweg wird dann automatisch ermittelt“ ist auch etwas kühn; in manchen Sprachen (etwa Haskell, Prolog) stimmt das recht weitgehend, während es etwa in LISP trotz Lambda-Kalkül nur bei manchen Problemen gelingt; LISP sich auch als ordinäre imperative Sprache nutzen ließe. Bei einer Abfragesprache wie SQL ist fraglich, ob man sie überhaupt als Programmiersprache einsortieren kann, aber sie erfüllt das Kriterium des automatisch ermittelten Lösungswes perfekt.

Es wäre also darüber nachzudenken, ob man bei Ada das Deklarativ-Kreuzchen stehenlässt oder vielleicht eine andere, eindeutiger zuzuordnende Sprache in die Tabelle der Beispiele einfügt.

Grüße --PerfektesChaos 10:06, 27. Apr. 2012 (CEST)

ADA ist ja zwischenzeitlich nicht mehr angekreuzt. Zu deinen Anmerkungen:

Pr-Sprachen können mehreren Pgm-Paradigmen folgen (siehe Programmierparadigma). Daraus ergibt sich, dass man zwar jeder Sprache ein bestimmtes Paradigma 'hauptsächlich' zuordnen kann, dass sich das Paradigma aber im eigentlichen Sinn auf die ProgrammierUNG bezieht, die ein Entwickler damit betreibt. Insofern kann man auch SQL 'einsortiert lassen', das ja, neben deinem Rückschluss 'erfüllt Kriterium perfekt', in vielen Quellen explizit als Beispiel für deklarativ genannt wird.

Grüße von--VÖRBY (Diskussion) 12:51, 16. Jun. 2012 (CEST)

Befehle

Dieser Textabschnitt ist m.E. nicht bzw. zu wenig aus der Sicht von Programmiersprachen (= Lemma) verfasst. Da steckt zu viel an Maschinencode und Prozessorlogik drin, z.B. das mit den Microprogrammen. Was ein Compiler/Übersetzer in diesem Zusammenhang tut, wird gar nicht klar. Auch sind viele Aussagen, z.B. zu Mikro- und Macroebene, schwer verständlich - und nicht nur für OMA's. --VÖRBY (Diskussion) 12:33, 26. Jul. 2012 (CEST)

Nachtrag: Eigentlich bin ich dafür, den ganzen Abschnitt 'Übersetzer' neu und sehr viel kürzer zu schreiben, und im Wesentlichen aufzählen, was ein Compiler mit dem Quelltext TUT. Denn der jetzige Text hat mit 'Programmiersprache' kaum etwas zu tun, sondern beschreibt Details zu Compiler, die dort auch ausführlich behandelt werden. Der Hauptartikelverweis sollte also dorthin zeigen, der bisherige Verweis auf Compilerbau ist unpassend, denn dort ist das bisher hier Beschriebene nicht mal erwähnt, geschweige denn ausführlicher beschrieben.
Wenn es hierzu keine Einwände gibt, würde ich den Umbau entsprechend vorbereiten und zur Diskussion stellen. --VÖRBY (Diskussion) 16:15, 27. Jul. 2012 (CEST)

ich gebe dir recht, diese Diskussion gehört nicht hierher! Meinen Segen hast du also --Herbert Klaeren (Diskussion) 17:30, 27. Jul. 2012 (CEST)

Neuentwurf 'Übersetzer'

Der Text wurde nach Übernahme in den Artikel HIER gelöscht.
Rekonstruktion ist erforderlichenfalls über die 'Versionsgeschichte' möglich. 

Diskussion dazu

Hallo, ich habe nun einen ersten Entwurf oben eingesetzt und dabei die Textteile, die mit der PrSpr nichts oder wenig zu tun haben, weggelassen. Siehe auch Kommentare im Text.
Auch nach der Textreduzierung könnte man der Ansicht sein, dass diese Beschreibung von 'Übersetzung' nur wenig mit 'Programmiersprache' zu tun hat, sondern eher zu 'Quellcode' passt; das läge 'näher' am Compiler. Für diesen Fall sollte der Entwurfstext nochmal gekürzt werden, d.h. auf die Aussage 'Übersetzung erforderlich' reduziert, mit Link auf 'Quellcode' und 'Maschinencode'.
Feinkorrekturen sind noch vorgesehen. 'Belege' wären ebenfalls nützlich (fehlten aber auch bisher). Feedbach erwünscht. VÖRBY (Diskussion) 10:15, 30. Jul. 2012 (CEST)

• Ja, fein; da alle Einzelheiten in den Hauptartikel gehören, kommt es hier nur darauf an, das weitere Geschehen nach dem Schreiben des Quellcodes verständlich darzustellen.
• Ein Bug ist allerdings drin: Ein Zwischencode hat nichts mit einem 'Link-Programm' zu tun; diese Bezeichnung wird ausschließlich für das Zusammenfügen von Modulen in maschinennahem Code zu einem mehr oder weniger ausführbaren Programm verwendet (oder Bibliothek). Einen einheitlichen Begriff für das Dings, das aus Zwischencode ein Maschinenprogramm macht, gibt es nicht; je nach Jahrzehnt bei Bytecode unterschiedlich, bei Java: Virtual Machine in der JRE. Auch mal „Interpreter“ genannt; dieses Wort ist aber in einem Artikel über „Programmiersprache“ heikel, weil es auch die Statement-weise Umsetzung des Quellcodes in sofort ausgeführte Maschinenbefehle meint.
• Deklarationen wären gerade keine „Befehle“ – wohl aber Statements oder Anweisungen.

Viel Spaß PerfektesChaos 12:54, 30. Jul. 2012 (CEST)

Danke für das Feedback. Rein aus der Sicht des Ablaufs ist der vom Compiler erzeugte und vom Linker gelesene Code doch wohl ein 'Zwischencode'. Dass er dem späteren ausführbaren Code sehr ähnlich ist, sollte m.E. da keine Rolle spielen; außerdem unterscheidet er sich in vielen Teilen (die man sicher hier nicht beschreiben sollte) von Letztgenanntem. Kennst du einen anderen Ausdruck dafür? Ich habe aber 'Linker' rausgenommen und durch 'Systemprogramm' ersetzt, damit sollten wir neutral sein.

Grüße von VÖRBY (Diskussion) 13:14, 30. Jul. 2012 (CEST)

Zwischencode ist etwas anderes.

• Linker verknüpfen Einzelmodule in kompiliertem plattformabhängigem Maschinen(nahen)-Code zu größeren Einheiten: Segmente, Bibliotheken oder ausführbare Programme; dabei werden innere Adressierungen aufgelöst.
• Zwischencode ist ein plattformunabhängiger Code, der gewissermaßen vorverdaut ist. Zu jeder Programmiersprache ließe sich solcher Zwischencode generieren, etwa indem man Kommentare und Whitespace aus dem Quellcode entfernt, konstante Ausdrücke auswertet und einzeln benannte Variablen durch nummerierte Elemente von Arrays ersetzt; schließlich die menschenlesbaren Namen intrinsischer Standardfunktionen ersetzt durch fest durchnummerierte Funktionsaufrufe (daher auch der Name Bytecode, als bis zu 255 Standardfunktionen über ihre Nummer und nicht über den textuellen Namen angesprochen wurden). Mit weiteren Optimierungen entsteht ein möglichst kompakter und schnell auswertbarer Code, der dann ggf. auch mit dem normalen Compiler möglichst schnell auf der Zielplattform kompiliert werden kann.

VG --PerfektesChaos 20:14, 30. Jul. 2012 (CEST)

Der "Zwischencode", den VÖRBY meint, heißt Objektcode. --Daniel5Ko (Diskussion) 21:39, 30. Jul. 2012 (CEST)

Danke für die Hinweise. Dass 'Zwischencode' ein offiziell definierter Begriff wäre, war mir bisher noch nicht untergekommen. Gibt es dazu Quellen - die man dort einstellen könnte? Nach wörtlicher Bedeutung wäre 'Zwischencode' alles, was zwischen Quellcode und ausführbarem Maschinencode liegt, egal in welchen Formaten. Ich denke aber, die entsprechende Textpassage jetzt neutral genug formuliert zu haben. Den 'Objectcode' (wie heißt dann der ausführbare?) brauchen wir dann nicht mehr. Wir wollen ja hier diese Sachverhalte auch nur kurz erwähnen, Details sollten bei den Hauptartikeln stehen.
Zur obigen Frage, ob der geänderte Text besser nach 'Quellcode' passt, schlage ich vor, ich aktualisiere zunächst hier den Abschnitt. Damit wäre 'Programmiersprache#Übersetzer' erst mal angepasst. Ob man danach noch was verschiebt, wäre eine zweite Aktion.
Wäre der Text ansonsten aus deiner Sicht ok? Was machen wir mit 'Belegen' - die auch schon bisher fehlten?
Grüße von --VÖRBY (Diskussion) 21:59, 30. Jul. 2012 (CEST)

Vorsicht:

• Zwischencode – plattformunabhängig; relativ selten eingesetztes Konzept; typisch etwa bei Java und LISP. Eine eigenständige Zwischenstufe für die Distribution. In der Laufzeitumgebung der Zielplattform dann die Umsetzung in plattformabhängigen Code.
• Objektcode – plattformabhängig; der klassische und verbreitete Fall. Der sollte schon noch erwähnt werden. Hier wird der Quellcode direkt für die Zielplattform kompiliert und das dann verteilt; sei es eigenständig ausführbar oder mit Bibliotheken.

Belege; tja, da gibt es Regalmeter. Ich hab jetzt grad nichts mit 2000er Jahreszahlen hier zu stehen, weil ich dieses Jahrtausend nur noch papierlos arbeite. Notfalls in der nächsten Stadtbibliothek nach einer gut verständlichen Einführung schauen, aber die Mitleser werden schon ein paar Lesetipps haben.

Sonst habe ich keine inhaltlichen Beanstandungen; lassen wir mal die anderen.

Schönen Abend --PerfektesChaos 22:32, 30. Jul. 2012 (CEST)

Habe die beiden Konzepte oben unterschieden. Weitere Details sind m.E. HIER nicht erforderlich. Inhaltlich meine ich aber, dass beiden Varianten Zwischencode und Objectcode sich durch mehr unterscheiden als durch Aspekte der SW-Distribution. Bei IBM-Großrechnern etwa war (vor vielen Jahren ?! ;-) Objectcode immer nur das 1:1 übersetzte Quellprogramm, das zur Ausführung immer mit anderen Modulen, und seien es auch nur Compilerspezifische Unterroutinen, ergänzt werden musste - und dann erst verteilt wurde. Danke für die Mitwirkung. --VÖRBY (Diskussion) 10:38, 31. Jul. 2012 (CEST)

Ich habe heute den oben entwickelten Text im Artikel eingestellt und oben - aus Platzgründen und damit nicht nochmal Änderungen vorgenommen werden - gelöscht. Ob er unter 'Programmiersprachen' richtig positioniert ist, wäre evtl. zu klären; jedenfalls sind die Aspekte, die nicht 'PrSpr-bezogen' waren, jetzt entfernt. Danke für die Mithilfe.--VÖRBY (Diskussion) 09:49, 1. Aug. 2012 (CEST)

• Zur Frage im BK:
  • Deklarationen legen vor allem auch Datentypen fest (hier: String); die Reservierung von Speicherplatz könnte im Fall der Allokierung von Feldern hingegen schon eine ausführbare Anweisung sein.
    • Es gibt rein deklarative Anweisungen und Mischformen, etwa die Zuweisung eines Initialwerts oder die Reservierung konstanter Felder. (Ob die reine Deklaration einer einzelnen Basis-Variablen schon die entsprechende Anzahl von Bytes für sie reservieren würde oder nicht, können Compiler unterschiedlich handhaben.)
  • Aufrufe können auch nicht-Systemfunktionen (selbst programmierte Unterprogramme) sein; die Unterscheidung von Systemfunktionen und benutzerdefinierten Funktionen ist seit dem stdlib-Konzept in C obsolet.
  • Unterscheiden würde ich zuoberst zwischen nicht-ausführbar (Deklarationen), ausführbar, und den genannten Mischformen.
    • Was nicht zu verwechseln ist mit deklarativen Programmiersprachen.
  • Ansonsten ist die Unterscheidung in „Befehlskategorien“ erstmal vollständig.
    • Die Berechnungen sind verbunden mit einer Zuweisung.
    • Die Textmanipulation ist eine Form der Berechnung.
    • Ich würde die Vokabel „Anweisung“ bevorzugen. Ein „Befehl“ ist in meinem Verständnis eine ausführbare Anweisung; reine Deklarationen sind keine Befehle und fallen nicht in „Befehlskategorien“.
• Ich bin bei Ablaufprinzipienunglücklich mit der Verbindung zwischen „interpretierte Sprache“ und „JVM oder .NET CLR“ – nach gebräuchlichem Sprachgebrauch wird bei einer interpretierten Sprache nach dem Umwandeln einer einzelnen Anweisung aus Quellcode in Maschinensprache diese Anweisung sofort umgesetzt (ausgeführt); sie können deshalb auch interaktiv sukzessive eingegeben werden und vor jedem neuen Statement kann das Ergebnis des vorhergehenden beobachtet werden. Mit JVM usw. hat das überhaupt nichts zu tun.
  • Jede Einheit in interpretierter Sprache ließe sich aber auch geschlossen kompilieren und dann erst (entsprechend parametrisiert) en bloc ausführen; klassischerweise spricht man dann von einem Skript.
• Was ein „Systemprogramm“ sein soll und was nicht, wäre sehr mühsam zu definieren; ich würde von Compilern einfach als einem „Programm“ oder „Werkzeug“ sprechen.
  • Wenn du übrigens innerhalb der momentanen Seite verlinken möchtest, wäre es glücklicher, den Seitennamen wegzulassen: [[#Übersetzer|...]]
• Was mir an dem ganzen Artikel noch fehlt, eigentlich schon in der Einleitung, ist der Hinweis, dass eine Programmiersprache für Menschen lesbar und verständlich sein muss. Dass eine Programmiersprache von Computern „verstanden“ würde, schreibt einem jeder Depp auf.

Viel Spaß weiterhin --PerfektesChaos 13:24, 2. Aug. 2012 (CEST)

Ich finde, die Frage nach einer Quelle sollte hier auch aufgegriffen werden, beginnend bei den (schon lange vorhandenen) gewagten Formulierungen in der Einleitung: Im zweiten Absatz der Einleitung wird von Programmiersprachen verlangt, lesbar zu sein. Die meisten sinnvollen Programmiersprachen haben das wohl auch zum Ziel. Es ist aber kein Kriterium, keine Charakterisierung aller Programmiersprachen. Sonst wären esoterische Programmiersprachen zum Teil keine Programmiersprachen (inbesondere Whitespace und Brainfuck). Dass die Bequemlichkeit ein Gegenpol zur Übersetzbarkeit sein soll (insbesondere Eindeutigkeit gegenüber Lesbarkeit) kann ich so pauschal nicht nachvollziehen und müsste belegt werden, genauso wie die Behauptung, dass die Nähe zu einer Anwendung zwangsweise eine Sprache für andere Anwendungen weniger geeignet macht.

Um den Diskussions-Abschnitt nicht zu sehr für Diskussionen über die Einleitung zu kapern, hier noch eine Bemerkung zum neuen Text: Ich finde, es besteht eine erhebliche Redundanz zu Computerprogramm#Übersetzung und Ausführung. Der Abschnitt hier ist ebenso aus der Perspektive eines Programms geschrieben, statt die Aspekte von Programmiersprachen zu behandeln. Ich finde, man muss nicht in jedem Artikel, der mit Programmierung zusammenhängt, alle Hintergründe zur Programmierung erklären. Deshalb fände ich es sinnvoller, den Abschnitt mehr aus der Sicht der Sprache zu formulieren. Wie beeinflusst die Sprache die Übersetzbarkeit, welche Spracheigenschaften haben welche bekannten Techniken hervorgebracht? --Zahnradzacken (Diskussion) 15:57, 2. Aug. 2012 (CEST)

Vielleicht wäre ein Disku-Abschnitt „Einleitung“ sinnvoll?

• Ich stimme dir zu, dass der mit dem Satz „im Spannungsfeld“ aufgebaute Gegensatz nicht notwendig besteht. Im Gegenteil, eine auf klaren Konzepten und einer durchdachten Struktur beruhende Sprache ist sowohl „formal“ befriedigender als auch besser zu verstehen; und somit ist die Eindeutigkeit für Mensch wie Maschine hilfreich. Die Vokabel „Bequemlichkeit“ stört mich auch; Lesbarkeit und Verständlichkeit haben nichts mit Bequemlichkeit dieser faulen Programmierer zu tun. Ohne mich jetzt durch die Versionsgeschichte wühlen zu wollen, sagt mir meine Erfahrung, dass hinter einer solchen Formulierung vermutlich eine längere Disku und viele, viele Versionen bis zu einer Kompromissfindung stehen.
• Zutreffend ist, dass für die esoterischen das Thema „Verständlichkeit“ gerade nicht im Vordergrund steht; wobei ich den übersichtlichen und aufgeräumten Quelltext von Whitespace sehr schätze. Ansonsten ist aber für produktive und „gute“ Sprachen Klarheit und Verständlichkeit für Menschen ein wesentlicher Aspekt und muss thematisiert werden. Prinzipiell kann man unendlich viele formale Sprachen konstruieren und jede zur Programmiersprache erklären; aber nicht alle Definitionen wären zu gebrauchen.

LG --PerfektesChaos 17:25, 2. Aug. 2012 (CEST)

Fortsetzung der Diskussion siehe #Einleitung / Redundanzen --VÖRBY (Diskussion) 19:20, 2. Aug. 2012 (CEST)

Undankbarer Artikel

Dieser Artikel ist immer noch sehr abstrakt und für den Laien kaum verständlich. Es erschließt sich nicht, WIE eine Programmiersprache funktioniert, wie es zu ersten Entwicklungen überhaupt kam, geschweige denn, wie es dazu kommt, dass ein Befehl dazu führt, dass etwas Bestimmtes auf einem Computer bzw. in einer Software geschieht. (nicht signierter Beitrag von 83.236.209.78 (Diskussion) 17:11, 31. Jul 2012 (CEST))

Hallo, du beziehst dich - siehe deine Formulierung 'immer noch' - wohl auf die aktuelle Anpassung des Artikels. Dabei zielen diese Maßnahmen allerdings nur auf das Kapitel 'Übersetzer'. Das zur 'Geschichte' Gesagte muss ich einfach mal so stehen lassen. Undankbar ist das Thema auch deshalb, weil es viele Stellen gibt, an denen man das von Dir Gesuchte (vom Befehl zur Ausführung) beschreiben könnte - ein altbekanntes Wikipedia-Problem. Und ich bin mir nicht sicher, ob 'Programmiersprache' dazu der richtige Artikel ist. Ich möchte dich aber auf die Artikel Software, Compiler, Maschinencode hinweisen (die z.T. hier verlinkt sind); dort findest du möglicherweise Antworten auf Deine Frage.

Im aktuellen Textumbau kann ich aber versuchen, noch etwas in 'Deine Richtung' einzubauen - falls das wirklich mit 'Programmiersprache' etwas zu tun hat. Grüße von --VÖRBY (Diskussion) 18:17, 31. Jul. 2012 (CEST)

Im Artikel gibt es übrigens das Kapitel 'Geschichte' - mit Verweis auf ein noch detaillierteres Kapitel zur Geschichte von Programmiersprachen. Ich hoffe, deine Anliegen sind einigermaßen geklärt. --VÖRBY (Diskussion) 09:49, 1. Aug. 2012 (CEST)

Einleitung / Redundanzen

Hallo zusammen, (Fortsetzung der Schlussdiskussion unter Diskussion zu 'Befehle'):
Ja, wir haben da wohl in ein Wespennest gestoßen. Und wie ein Leser meinte, ein 'undankbarer Artikel'. Soviel nur von meiner Seite:

• Meine Absicht zielte zunächst darauf, das Kapitel Übersetzer zu entrümpeln - Zeug raus, das nicht zu PS gehört. Zusätzlich habe ich die Übersetzungsfunktionen kurz eingefügt, die restlichen Teilkapitel i.W. belassen.
• Im Nachgang habe ich dann die Einleitung etc noch etwas überarbeitet und bequellt, ohne aber die bisherigen Aussagen 'über den Haufen' zu werfen.
• Ich würde den jetzigen Text von 'Übersetzer' gerne eher noch reduzieren als um die Anmerkungen von dir, PerfektesChaos, zu erweitern.
• Vor allem finde ich auch die Anmerkung von Zahnradzacken richtig, dass HIER im Artikel zu wenig über PS und zu viel über Programme, Execution, Maschinencode etc. steht. Das hatte ich oben auch schon angedeutet.
• In der Einleitung findet sich (jetzt) der Hinweis auf die Lesbarkeit durch Menschen deutlicher.

MICH hatten in erster Linie die für das Lemma unpassenden Texte in 'Übersetzer' gestört. Und ich könnte evtl. die jetzt noch bestehenden Redundanzen im Artikel selbst irgendwie bereinigen. Inhaltlich-theoretisch ist 'PS' nicht so ganz mein Spezialthema. Pragmatisch scheint es mir so, dass die Artikelqualität durch weitere Reduzierung von Texten (zu fremden Lemmas) verbessert werden könnte. Die Texte zu Charakterisierungen (Verständlichkeit vs. Performance ...) sollten sich evtl. unter Geschichte der Programmiersprachen finden - was aber den Gegenstand unserer Diskussion erweitern würde. Letztlich: Um wirklich konsistente und weitgehend redundanzfreie Beschreibungen herzustellen, müsste man wohl viele andere Lemmas auch noch in eine Reorganisation einbeziehen. Das scheint mir aber zu aufwändig.
WER könnte also WAS tun? --VÖRBY (Diskussion) 18:10, 2. Aug. 2012 (CEST)

Seid Ihr noch in der Diskussion? Was mich betrifft würde ich die folgenden Änderungen vornehmen:

• Übersicht: Absatz 2 und 3 ersatzlos streichen (Redundanz).
• Übersetzer: Nur Absatz 1 im Artikel belassen, evtl. als Unterkapitel zu 'Übersicht'. Die 2 anderen Unterabschnitte in 'Compiler' einarbeiten - sofern dort nicht schon vorhanden. Grafik evtl. bei 'Übersicht' einstellen.

Sollte ich das tun? ERLEDIGT bis 9.8.12

Darüberhinaus - siehe auch eure eigenen Anmerkungen:

• Einleitung: 2. Absatz wird angezweifelt. Wer könnte ihn belegen oder umschreiben? Oder löschen? ERLEDIGT
• Übersicht: Im Absatz 4 ist der anfängliche Text fragwürdig und unbelegt. Ob der Absatz überhaupt raus kann? Performance-Aussage sollte aber irgendwo bleiben.
• Sonstiges: Der 'Hello-world' Absatz scheint mir trivial, der letzte Satz zeigt aber einen sinnvollen Link.

Grüße von --VÖRBY (Diskussion) 12:29, 4. Aug. 2012 (CEST)

• Meine obigen Anmerkungen dienten lediglich dazu, inhaltliche Missverständnisse in den Textvorschlägen zu vermeiden. Bereits zu Beginn hatte ich angemerkt, dass der Einzelabschnitt beliebig kurz oder ausführlich gehalten werden kann, weil die eigentliche Arbeit vom verlinkten Hauptartikel zu leisten ist; hier geht es um eine sinnvolle Zusammenfassung im Kontext der Programmiersprache und deren Verständnis. Ich stehe Kürzungen also nicht entgegen.
• In der Einleitung würde ich die in Klammern gesetzte „Eindeutigkeit“ ersatzlos streichen. Das ist praktisch eine Selbstverständlichkeit und stellt fast schon in Frage, ob es mit der Definition der formalen Sprache korrekt zugegangen ist. Ohne Eindeutigkeit für Maschine wie Menschen ist alles nix. Der Aspekt „Übersetzbarkeit“ spielt eher auf Kinderkrankheiten früher Jahrzehnte und schlichte Parser an; seitdem kann man aber so ziemlich alles übersetzen. Gemeint wäre also eher „leichte Übersetzbarkeit“ – die Bequemlichkeit beim Compilerbau; vs. der „Bequemlichkeit der Anwendungsprogrammierer“. Es gibt wenige Fälle, wo sich die konkrete Interpretation erst zur Laufzeit erschließt; dann jedoch nach eindeutigen Regeln.
• Ansonsten gucke ich nur mit einem Auge vorbei, habe hier keine Aktien und bin offen für Strukturierungswünsche der Kollegen.

Viel Vergnügen weiterhin --PerfektesChaos 16:13, 4. Aug. 2012 (CEST)

Ich habe deine Anmerkungen in meine Bearbeitung aufgenommen. Vielleicht wirst du trotzdem Bedarf sehen, etwas daran zu ändern, dann nur zu. Zu deinem Beitrag weiter oben noch eine Randnotiz: Ich habe im Diskussionsarchiv keine Diskussion gefunden, die zu einem Kompromiss geführt hätte. Es scheint vielmehr spätestens seit der ersten gescheiterten Kandidatur 2005 fast nur Kritik zu geben. Die Einleitung in der heutigen Form entstand durch eine einzige Bearbeitung (und war wohl eine Verbesserung).

Zur heutigen Änderung: Ich habe den zweiten Absatz entfernt. Man konnte zu viel hineininterpretieren (mir war etwa nicht klar, was die Klammerung bei Bequemlichkeit bedeuten sollte: das schwammige Wort "Sicherheit" ist zum Beispiel womöglich nicht unbedingt ein Teilaspekt des schwammigen Konzepts "Bequemlichkeit", die Klammern wären dann eine fortgesetzte Aufzählung). Die Übersetzbarkeit wusste ich auch nicht ganz einzuordnen. Dass man so ziemlich alles übersetzen könne, stimmt nur mit Blick auf die gereiften Programmiersprachen. Jeder Entwurf einer neuen Sprache muss sich der Frage durchaus stellen. Ob nun "leicht übersetzbar" oder "gut genug durchdacht", beides fand ich zu vage und nicht angemessen für eine Einleitung. Auch das "Spannungsfeld" GPL/DSL war zu detailliert für eine Einleitung. Besser wäre es, die Geschichte oder ein wenig Grundlegendes zu ergänzen, mir fällt da aber gerade nicht viel Wohldurchdachtes ein. --Zahnradzacken (Diskussion) 01:07, 7. Aug. 2012 (CEST)

Ich will auch nur kurz signalisieren, dass ich nicht völlig weg bin, aber die inhaltliche Überarbeitung hier ist mühsam. Deshalb zunächst Dank und Lob an dich, VÖRBY, für das richtige Anpacken. Hoffen wir, dass der seidene Motivations-Faden nicht reißt. Deshalb lasse ich lieber die Finger von Geschichte der Programmiersprachen. Ich habe auch nicht zum Ziel, Redundanz völlig abzuschaffen, davon bin ich gar kein Freund. Im Abschnitt zum Übersetzer war die Redundanz aber besonders groß, weil der Bezug zum Artikelthema verloren gegangen ist. Ich stimme zu, dass hier durch Kürzen die Artikelqualität vorläufig steigt und auch die Aufforderung an die versammelte Leserschaft deutlicher wird, dass hier noch nicht alles Wichtige geschrieben steht.

Absatz 2 der Einleitung werde ich ein wenig abändern, vielleicht kann er dann bleiben. Der Rest wird bestimmt auch nach und nach besser :) --Zahnradzacken (Diskussion) 19:36, 6. Aug. 2012 (CEST)

Danke für die Mitwirkung. Schaust du bitte auch mal bei Compiler rein. Dort habe ich die hier 'fremden' Textteile schon mal eingestellt. Nach einigen Tagen möchte ich HIER entsprechend kürzen, natürlich nicht auf "Null Prozent Redundanz". Unser 'Steckenpferd' "Belege" konnte ich leider noch nicht "einfangen". Ich denke aber, dass wir noch welche finden werden und (ggf. mit textlicher Anpassung) ergänzen können. Grüße von --VÖRBY (Diskussion) 20:09, 6. Aug. 2012 (CEST)

Ich habe die strukturellen Redundanzen zu Compiler heute ausgebaut und oben im Disk-Text kurze ERL-Bemerkungen eingestellt. Zumindest i.S. DIESES Abschnitts hier ist die Überarbeitung also abgeschlossen. Vorlage ÜBERARBEITEN ist gelegentlich noch zu entfernen (?). --VÖRBY (Diskussion) 17:43, 9. Aug. 2012 (CEST)

@Benutzer:ʘx, zu den Änderungen vom 3.10.12

Aus deinem Fauchen in den Bearbeitungskommentaren leite ich ab, dass ich besser diskutiere, statt zu editieren. Überwiegend fauchst du gegen meine – zum Teil unklugen – Formulieren, zum Teil aber auch gegen die Definition des Duden-Informatik (wirst du hoffentlich gelten lassen, wie auch den dtv-Atlas), nämlich bezüglich der "Formulierung von Datenstrukturen". Im Duden steht es genau so: "Formulierung von Rechenvorschriften, d.h. von Datenstrukturen, Algorithmen und Prozessen". Wie du selbst anmerkst, werden auch Datenstrukturen in Programmiersprachen beschrieben. Für die Duden-Redaktion war nun Algorithmus und Rechenvorschrift offenbar nicht das gleiche. Du hättest trotzdem den Satz so formulieren können, dass der mögliche Widerspruch entfällt anstelle des Wortes Datenstrukturen. Da du aber gelöscht hast, nehme ich an, dass du lieber auf das Wort verzichtest als auf den Informationsverlust. Kannst du das begründen?

Dann bezeichnest du "Arbeitsmittel der Programmierung" als Unfug und blabla. Warum? Vielleicht weil es das Wort "Arbeitsmittel" nicht ganz trifft, da es eher auf Programmierumgebungen zutreffen würde? Angesichts der Laien-Leser finde ich einen Satz gut, der kurz ausdrückt, dass Programmiersprachen zum Programmieren da sind, und man hat einen Blaulink auf den Artikel, der sich mit der Tätigkeit befasst, der zurzeit nichtmal unter "Siehe auch" zu finden ist. Oder worin äußern sich Unfug und blabla?

A propos blabla: Hochsprachen sind nicht per se problemorientierter als Maschinensprachen. Sie sind nur weniger geräteorientiert.

Und warum löschst du die Erläuterung der Maschinensprache, inklusive Wikilink?

--Zahnradzacken (Diskussion) 15:17, 7. Okt. 2012 (CEST)

• Ich gebe gerne zu, dass der dtv-Atlas zur Informatik nicht gerade eine Superquelle ist. Allerdings ist das, was ich darin gefunden habe, exakter als das, was ich bisher vom Duden gehört habe. Meinetwegen können wir den dtv-Atlas auch streichen, war nur ein Versuch.
• "Formulierung von Rechenvorschriften, d.h. von Datenstrukturen, Algorithmen und Prozessen, d.h. von Datenstrukturen, Algorithmen und Prozessen": Hier wird nunmal was Falsches ausgedrückt. Algorithmus und Rechenvorschrift sind Synonyme (allerdings ist "Rechenvorschrift" seltener). Aber eine Datenstruktur ist keine Rechenvorschrift. Das ist nicht meine persönliche Meinung, sondern einfach ne informatische Tatsache. Ich habe eben Datenstrukturen wieder eingebaut, aber ich bin mir nicht sicher, ob es so wirklich unmissverständlich ist.
• Dann bezeichnest du "Arbeitsmittel der Programmierung" als Unfug und blabla. Warum? Ich bezeichne es als Unfug, weil es überhaupt nichts aussagt. Ein Arbeitsmittel der Programmierung ist alles mögliche: mein Hirn, meine Tastatur, mein Rechner, mein Compiler, etc. Noch dazu stand im Artikel der bestimmte Artikel: "DAS Arbeitsmittel". Das ist besonders daneben. Eine Programmiersprache ist kein Werkzeug, und schon gar nicht DAS Werkzeug. Die Kategorie stimmt einfach nicht. Dass Programmiersprachen zum Programmieren da sind, geht gleich aus dem ersten Satz der Einleitung hervor. Falls tatsächlich ein Konsens bestünde, dass das nicht klar wird, dass man mit Programmiersprachen programmiert (!?!), dann sollte man das ohne das Wort "Arbeitsmittel" erklären.
• A propos blabla: Hochsprachen sind nicht per se problemorientierter als Maschinensprachen. Sie sind nur weniger geräteorientiert. Und was bedeutet "weniger geräteorientert"? In welche Richtung gehen sie dann? In Richtung der Probleme. Dass sie unter Umständen sich nicht an genau dem Problem orientieren, dass man gerade lösen will, ist schon klar, und dass domänenspezifische Sprachen NOCH problemorientierter sein können (bzgl. eines bestimmten Problems aber nur), ist auch klar, aber "problemorientiert" stimmt dennoch. Sogar C als niedrigste Hochsprache ist problemorientiert, nur orientiert es sich an einem recht niedrig angesiedelten Problem.
• Und warum löschst du die Erläuterung der Maschinensprache, inklusive Wikilink? Da stand, man würde Computer mit Maschinensprachen "unmittelbar steuern". Erstens ist das sehr ungut, zu behaupten, mit einer Sprache würde man einen Rechner steuern. Nicht mit einer Sprache tut man das, sondern mit einem Programm, das in einer Sprache formuliert ist. SO wird ein Schuh draus. Zweitens ist nicht klar, was "unmittelbar" bedeutet, und falls man versuchen würde, es zu erklären, würde man da in der Einleitung Chaos stiften. Deswegen hielt ich es für das beste, den Rotstift anzusetzen. Weniger ist oft mehr, insbesondere in Einleitungen. Eine Einleitung sollte nicht überladen werden.
• Konnte ich meine Standpunkte halbwegs verständlich machen? ʘχ (Diskussion) 00:37, 9. Okt. 2012 (CEST)

1. Lassen wir den dtv-Atlas mal außen vor, ich kenne ihn nicht und will nicht darauf herumhacken. Der Duden ist bei Informatik keine Autorität, aber wenn die Definition per ref-Tag darauf verweist, kann man die Definition nicht einfach umformulieren und den Verweis stehen lassen.
2. Ja, die Formulierung ist blöd. Eine Quelle, die deiner neuen Formulierung näher kommt ist die hier. Sehe momentan kein Problem mit Missverständlichkeit in deiner neuen Formulierung. Danke schonmal.
3. Du änderst munter nach deinen Maßstäben, möchtest aber einen Konsens für meine Bedenken? Natürlich kann man sich viel aus dem Wort "Programmiersprache" ableiten, aber oft haben Wörter ja eine andere Bedeutung als sie den Anschein machen. Mit dem Ziel einer auf einen Blick leicht zu erfassenden Einleitung verbinde ich den Gedanken, dass manche Leser (speziell die, die aus solchen Basis-Artikeln ihr Wissen eines für sie neuen Gebiets entnehmen) bei Wörtern wie "formale Sprache" oder "Algorithmus" zunächst nach greifbaren Sätzen suchen, die die naheliegende Bedeutung bestätigen und nicht intransparent umschreiben. Das Wort "Arbeitsmittel" spielt dabei natürlich keine Rolle.
4. Bei "problemorientiert" könnten wir abdriften. Das Wort ist zu vage ("<Komparativ> geräteorientiert" natürlich auch), weil daraus nicht hervorgeht, ob ein Problem gemeint ist oder das Problemlösen allgemein oder irgendwas dazwischen. Was ist das Problem, an dem C näher dran ist als Maschinensprache?
5. Nein, ich schrieb dass Maschinensprache zum Steuern dient, nicht dass sie steuert. Den Fehler, dass man mit Sprachen steuern würde, hatte ich weiter oben gemacht, hier nicht. Das Wort "unmittelbar" ist natürlich auch ungenau, aber mit dem Argument "nicht klar" könnte man sehr viel löschen. Egal, wie ausführlich erklärt würde, an irgendeiner Stelle würde vereinfacht, verbildlicht, würden Details unterschlagen. Daran sollte es nicht scheitern, auf Maschinensprachen zu verweisen, um dem Leser wesentliche Begriffe im Zusammenhang zu nennen.
6. Deine Standpunkte sind nun verständlich, auch wenn ich weder deine Ansicht zum Umfang von Einleitungen teile (Nach meinem Geschmack sollte eine Einleitung einen Themenüberblick verschaffen, in Übereinstimmung mit dem Artikelinhalt und natürlich ohne auszuufern) noch die Strategie des Rotstifts bevorzuge, wenn der Versuch einer in der Komplexität reduzierten Einleitung nicht voll geglückt ist. Aber nachdem ich inzwischen deine Ausführungen auf deiner Benutzerseite gelesen habe und deine Ziele für Artikeleinleitungen kenne, könnten wir hier voran kommen, sofern du meine Einmischung nicht missbilligst. --Zahnradzacken (Diskussion) 00:39, 10. Okt. 2012 (CEST)

Senf zum Thema Rotstift: Die Einleitung darf gerne ausführlicher sein.

Momentan ist der zweite Satz wenig hilfreich: Statt "Sie" könnte es heißen "Solche Programme". Statt "Anweisungen" sollte "Anweisungen oder Regeln" stehen (gerne ausführlicher), sonst wären Prolog und XSLT keine Programmiersprachen. – Rainald62 (Diskussion) 20:34, 24. Mär. 2013 (CET)

Die Definition schließt deklarative Programmiersprachen nicht ein (erl.)

Die Definition Eine Programmiersprache ist eine formale Sprache zur Formulierung von Datenstrukturen und Algorithmen, d. h. von Rechenvorschriften, die von einem Computer ausgeführt werden können - zumindest in Kombination mit der Definition Ein Algorithmus ist eine aus endlich vielen Schritten bestehende, eindeutige und ausführbare Handlungsvorschrift zur Lösung eines Problems oder einer Klasse von Problemen - schließt deklarative Programmiersprachen nicht mit ein, bei denen gerade keine Algorithmen, keine Rechenvorschriften und keine aus endlich vielen Schritten bestehende, eindeutige und ausführbare Handlungsvorschriften formuliert werden , sondern normalerweise nur Fakten und Regeln bzw. mathematische Definitionen. Der Algorithmus, wie diese Regeln auf die Fakten angewendet werden, steckt im Interpreter der Sprache und nicht im in der Programmiersprache geschriebenen Quellcode. Selbst wenn ein Compiler verwendet wird, der aus den Regeln und Fakten ein direkt ausführbares Programm generiert, gelingt dies nur, weil der Compiler den Algorithmus (mit)generiert, der gerade nicht im Quellcode stand. Wer kennt eine bessere Definition bzw. kann eine solche formulieren? --87.184.129.27 07:48, 6. Aug. 2013 (CEST)

Hier liegt ein Missverständnis vor. Du schreibst:

Der Algorithmus, wie diese Regeln auf die Fakten angewendet werden, steckt im Interpreter der Sprache und nicht im in der Programmiersprache geschriebenen Quellcode.

Wovon du hier sprichst, ist die Semantik einer Programmiersprache. Die steckt immer in der Implementierung des Compilers/Interpreters, das ist unabhängig von der Art der Sprache. Nicht nur bei Prolog, auch bei C bestimmt der Compiler, was ein Programm eigentlich tut, d.h. was seine Semantik ist.

Das nächste Problem: Was ist denn eigentlich ein "Schritt" bzw. eine "Handlungsvorschrift"? Was ist das bei C? -- Diese Frage wird letztlich durch eine Semantik von C beantwortet. Auch für Prolog oder Haskell könnte man eine Semantik angeben, die "Schritte" oder "Handlungsvorschriften" definiert, und schon landet man wieder beim von dir zitierten Algorithmenbegriff. ʘχ (Diskussion) 22:10, 6. Aug. 2013 (CEST)

@ʘχ geht am ersten Beitrag völlig vorbei, hat nichts damit zu tun. Das die „Semantik immer in der Implementierung bzw. im Compiler steckt“, wurde nicht bestritten, sondern darauf wurde sogar hingewiesen. Es wurde bemängelt, dass die Definition deklarative Programmiersprachen ausschließt, wie es bei der nicht-deklarativen Programmiersprache C ist und dass „man“ dort „wieder“ beim Algorithmenbegriff „landet“, ist etwas, was hier überhaupt nicht interessiert. Und selbst wenn man bei einer deklarativen Sprache „wieder beim Algorithmenbegriff landet“ – dass man bei dem irgendwie „landet“, wurde nicht bestritten. Es wurde bemängelt, dass hier Programmiersprachen unberücksichtigt bleiben, in denen die zu verwendenden Algorithmen (bei denen „man“ dann irgendwie „landet“), im Code nicht bezeichnet werden. --Lückenlos^wecken! 11:31, 6. Jul. 2015 (CEST)

Ich muss da Uwe Lück zustimmen; in z.B. Prolog "formuliert der Quelltext keinen Algorithmus", wie das z.B. ein C-Programm tun muss. Gerade das ist ja der Haupt-"Witz" einer deklarativen Programmiersprache. Allerdings sind diese Sprachen deutlich weniger verbreitet, und -hm- 'implizit' ist natürlich schon ein Algorithmus "im Hintergrund mit dabei".

Ich würde daher ungern die Einleitung (komplett) umformulieren ~ genügt es auch, an die Einleitung einen Absatz (aus 1-2 Sätzen) anzuhängen? Z.B.:

"Bei deklarativen Programmiersprachen ist der Ausführungsalgorithmus schon vorab festgelegt und wird nicht im Quelltext ausformuliert/beschrieben, sondern es werden nur seine (Start-)Parameter, (Rand-)Bedingungen und Regeln festgelegt, die das Ergebnis erfüllen muss."

Oder so was ähnliches.

--arilou (Diskussion) 14:00, 8. Jul. 2015 (CEST)

An 87.*: Habe die Einleitung nebenan eben noch ein wenig überarbeitet und denke auch daß der hier genannte Hinweis (zur bisher unzureichenden sogenannten Definition – auch schon vor meiner Überarbeitung) nicht mehr zutrifft und daß wenigstens dieser Abschnitt hier damit erledigt sein dürfte. -- 78.55.166.27 12:14, 17. Dez. 2019 (CET)