Diskussion:Programmieren/Archiv1

Kategorie:Programmiersprachen

Habe gerade alle Aufgeführten Programmiersprach-Seiten, die es im WikiBooks gibt aufgesucht und in die Kategorie Programmiersprachen gepackt. Leider weiß ich nicht, wie man zu einer Kategorie-Seite verlinkt, sonst könnte man die Liste aus der Seite streichen und mit einem Link ersetzten Genrich 07:41, 5. Nov 2004 (UTC)

Das geht mit [[:Kategorie:FooBar]] entsprechend mit |textlabel oder ohne. --Progman 14:58, 1. Jan 2005 (UTC)

C, C++, Java, C#

Die Aussage, daß C, C++, Java und C# aufeinander aufbauen, halte ich doch für sehr gewagt. Besonders die Folgerung, daß es reicht, eine der Sprachen zu lernen, dann wird das mit den anderen schon passen.

Natürlich haben die Sprachen eine ähnliche Syntax, mehr oder weniger von C abstammend. Aber, Programmieren besteht nicht einfach aus der Aneinanderreihung von sytaktisch korrekten Statements.

Es ist ein gewaltiger Unterschied, ob man strukturiert programmiert ( oder objekt-orientiert. Die unterschiedlichen Paradigmen bedingen eine unterschiedliche "Denke" und Ausbildung. An dem alten Spruch, daß C Programmiere für immer für das Programmieren in C++ verdorben sind, ist schon was dran. Gerade weil die Syntax so ähnlich, aber die Paradigmen so unterschiedlich sind, fällt die Umstellung schwer (hinzu kommt bei C++ noch erschwerend hinzu, daß man in C++ wie in C programmieren kann, was für C-Programmierer natürlich sehr verlockend ist).

Weiterhin ist es ist auch ein gewaltiger Unterschied, ob man OO mit oder ohne Garbage-Collection programmiert. Muß man mangels GC selber aufräumen, dann versucht man eher, die "Verbreitung/Verteilung" von Objekten (Pointer auf Objekte) in der Applikation klein zu halten. Man ist doch sehr bemüht, den Kontrollfluß im Programm so zu gestalten, daß man garantiert einen, aber nur genau einen, Punkt im Programm erreicht, an dem das Objekt explizit freigegeben wird. Hat man eine GC, streut man die Objekte eher etwas unbedarft "in der Gegend" rum. Die GC räumt's schon weg, wenn niemand mehr das Objekt braucht, egal wo im Kontrollfluß das mal passiert.

Und, als ob das nicht genug wäre, all diese Sprachen haben unterschiedliche Bibliotheken. Man kann eine Sprache nur effektiv nutzen, wenn ich auch die Standard-Biblotheken der Sprache beherschen. [Ok, in C++ hat man noch die C Standard-Bibliotheken (für diejenigen, die C++ wir C programmieren wollen)]. Ein Großteil des Erlernens einer Sprache besteht darin, die Bibliotheken zu lernen, die Syntax ist nur Basis-Handwerk.

Wenn man weiß, daß C nur 21 Schlüsselwörter hat (Java vielleicht 30), dann kann man sich vorstellen, daß die Leistungsfähigkeit der Sprachen bestimmt nicht von deren Syntax kommt, sondern von den zugrunde liegenden Philosophien und den Standard-Bibliotheken.

Worauf ich hinaus will: Auch wenn die Syntax diese Sprachen so ähnlich ist, sollte man sie besser als völlig unterschiedliche Sprachen behandeln. Sie unterstützen unterschiedliche Paradigmen, haben völlig unterschiedliche Bibliotheken und laufen auch noch in völlig unterschiedlichen Umgebungen, z.B. Java: Cross-Platform (wenn man Glück hat :-), C#: Nur Windows (wenn man mal das lange noch nicht fertige Mono ignoriert). C/C++: Native Binaries, Java/C#: Virtuelle-Maschine.

---

Was soll der Sprachenstreit und die Auswahlkriterien für eine Programmiersprache?

Ich bin ehrlich gesagt der Meinung, daß dieser ganze elende Sprachenstreit in einem Text für Programmieranfänger nichts zu suchen hat. Ich bin ganz dicht dran, den gesamten Teil über die Auswahl einer geeigeneten Programmiersprache aus dem Text rauszustreiche. Ein Anfänger kann die dort so schön mit akademischer Genauigkeit aufgeführten Abwägungen mangels Erfahrung und Informationen einfach nicht durchführen. Sie sind für einen Anfänger auch völlig irrelevant. Was soll so ein Zeug wie "Wollen sie schnelle oder langsame Programme schreibe? Dann ...". Wir reden hier von Anfängerprogrammen. Die werden nicht toll. Die haben ganz andere Probleme als 10% oder 20% Leistungseinbruch aufgrund der "falsch" gewählten Programmiersprache. Ich habe noch keinen Anfänger getroffen, der sich über Geschwindigkeitsprobleme seine Hello World Programms beschwert hat.

Und wenn ich mal richtig üble Laune haben, dann werfe ich auch gleich die Sprachenstreitereien aus dieser Diskussion raus :-) Ich kann es einfach nicht mehr sehen. Was soll den das Gejammere, dass in einem Anfängertext C gar so schlecht (nicht neutral) behandelt wird? Interessiert es wirklich, warum man zwischen normalen Sprachen und Skriptsprachen unterscheidet? Soll hier wirklich unbedingt jede furz-exoten-akademiker-experimentelle-steinzeit-kindergarten-profi-massen-oder-was-auch-immer Programmiersprache Erwähnung finden?

Zustimmung und Ablehnung zugleich. Zustimmung darin, daß die ganzen (subjektiven) Ansichten und vor allen die Streitereien raus müssen. Ablehnung allerdings gegen z.B. Geschwindigkeitsaussagen. Wir sollen hier Anfängern einen Einblick in das Programmieren geben. Bevor man konkrete Sprachen lehrt, sollte der Leser erstmal "sehen", was Programmieren überhaupt ist. Wenn er das weiß, kann man ihm die unterschiedlichen Paradigmen näher bringen (die hier momentan irgendwo unter der Nummer 8 versteckt sind, zudem noch als tote Links), und wenn man das hat, kann man die (subjektiv) wichtigen Sprachen erwähnen, und beschreiben. Ob man die anderen danach noch der vollständigkeit halber aufführt, ist eine andere Frage. Sicherlich ist es aber wichtig, Anfängern für Anfängern verständlich die Unterschiede der Sprachen auf zu zeigen, damit diese - sich ein erstes Bild vom Programmieren gemacht - entscheiden können, welche Sprache sie lieber wählen wollen. Es gibt Dinge, die man sinnvollerweise in OOP macht (insbesondere GUIs lassen sich so wesentlich einfacher realisieren, als im Imperativen Stil), aber schreib mal ein gzip in OOP. Das hat meiner Meinung nach einfach keinen Sinn. Bevor sich ein Anfänger also entscheiden kann, ob er z.B. OOP, will oder nicht, sollte er die Ansätze kennen gelernt und verstanden haben. Der aktuelle Stil, z.B. so ein Quatsch von wegen »4.3.3 Abstraktionsloch (eine Gegenmeinung): Wir haben Sie jetzt hoffentlich überzeugt, dass es besser für Sie ist, eine Hochsprache zu benutzen. Wenn Sie sich jetzt aber die reale Programmiererwelt ansehen, dann werden Sie festellen, dass viele Leute diesen weisen Rat einfach ignorieren. Wenn Sie sich zum Beispiel GNU (http://de.wikipedia.org/wiki/GNU) Software wie Linux (http://de.wikipedia.org/wiki/Linux) oder GNOME (http://de.wikipedia.org/wiki/GNOME) ansehen, dann werden Sie feststellen, dass diese im guten, altehrwürdigen C geschrieben sind. Warum das denn?« sollte natürlich aus diesem Buch möglichst bald verschwinden. Es ist nicht nur reine Stimmungmache gegen C (und gegen Linux und Gnome) sondern ist auch noch schlicht falsch (Hochsprache ist im Wesentlichen alles außer Assembler und Maschinensprache). C ist sicherlich eine alte Sprache, aber das nicht sie nicht zu einer »Niedrigsprache« (um mal ein neues Wort zu schöpfen). --Bodo Thiesen 03:31, 18. Aug 2004 (UTC)

Welcher Sprachenstreit denn??

Wo genau ist eigentlich der Sprachenstreit, von dem hier immer die Rede ist?

Dieser hier:

5.1.6 Lernen Sie alle!
[...]
2. Wenn Sie gut sein möchten, lernen Sie eine Hochsprache, eignen sich aber auch gutes Grundwissen in C und Assembler an.

C ist offensichtlich keine Hochsprache mehr - wurde wohl seit ich das letzte mal in de.comp.lang.c war geändert - vor einem halben Jahr war es nämlich noch eine.

Auch die nächste Aufzählung zeigt, daß der Autor ein guter propagandistischer Popolist ist, aber von objektiver Darstellung der Sprachen nichts hält:

2. Wenn Sie eine Menge Ärger haben wollen, ohne das zu erreichen, was Sie eigentlich wollen, dann versuchen Sie C oder Assembler zu erlernen.

Ich programmiere jetzt seit über 5 Jahren in C und habe damit überhaupt keinen "Ärger". (Ich behaupte allerdings *nicht*, C sei unbedingt gut für Anfänger geeignet, behaupte dies aber erst recht nicht von Java oder anderen Sprachen die man gerne Einsteigern vor die Füße legt.)

Und dann erdreistet sich der Autor im Absatz unmittelbar *vor* »5.2.2 Nutzen Sie die Einfachheit (eine Meinung)« folgendes zu sagen:

Programmierung in Assembler kann in schnelleren Programmen als mittlere 
und höhere Sprachen resultieren. Moderne, optimierende Compiler sind aber 
in der Regel besser im Optimieren von Code als Sie es sein werden.

Java schneller als Assembler? Also sorry, aber javac kann von mir aus so gut optimieren, wie er will, das in Assembler geschriebene Programm wird immer schneller sein, außer man macht dort etwas ganz arg falsch.

Und dann wiederholt er immer wieder seine Gebetsmühle: »Nutzen sie das einfachste«, oder »Benutzen sie Hochsprachen« (für ihn ist C ja keine Hochsprache sondern eine - rofl »Mittelsprache«. Wat soll das eigentlich sein? So wie Mittelhochdeutsch? (Sorry für den Sarkasmus, aber ich beschränke den immerhin auf die Diskussionsseite ...)

Allerdings bilde ich mir ein, daß viel von dem subjektiven Kram inzwischen entfernt wurde, ich bilde mir ein, der Text war schon mal schlimmer. --Bodo Thiesen 01:15, 30. Nov 2004 (UTC)

Nachtrag

»Die verbreiteten Programmiersprachen«:

Die meistgenutzten und verbreitetsten Programmiersprachen sind wohl C 
und C++. C++ enthält C fast vollständig, weshalb sich C-Programme in 
der Regel auch als C++-Programm kompilieren lassen.

Ach?

$ cat test.c
#include <stdlib.h>
int main() { int * data=malloc(100); }
$ gcc test.c
$ gcc -x c++ test.c
test.c: In function `int main()':
test.c:2: invalid conversion from `void*' to `int*'

Wer offensichtlich im besten Fall C oder C++ (aber auf keinen Fall beide Sprachen) kennt, sollte nicht solche Behauptungen aufstellen. Und nein: Dies ist kein Spezialfall, malloc ist in C ein so elementarer Bestandteil wie new in C++ und Java, und kommt in jeder siebten Zeile vor (oder so ähnlich ...). Und dann im folgenden Absatz noch das Märchen über die Kompatibilität ...

Ich hab jetzt mal diesen Absatz ersatzlos gestrichen, habe dabei aber nicht berücksichtigt, ob sich der folgende Absatz noch darauf bezieht. --Bodo Thiesen 01:38, 30. Nov 2004 (UTC)

Allgemein finde ich das Buch noch sehr POV. Ich denke, es währe besser im Kapitel Wählen der Programmiersprache die verschiedenen Sprachen mit ihren Vor- und Nachteilen vorzustellen, anstelle hier eine Empfehlung abzugeben. Wer macht mit? -- Daniel B 13:05, 30. Nov 2004 (UTC)

Meine Baustelle ist ja wo anders, aber ein Lob an Dich, die Beschreibung der Programmiersprachen ist auf jeden Fall um vielfache Besser, als der Schrott, den Du bei der Gelegenheit ja auch gleich entsorgt hast. Ich weiß allerdings nicht, ob man die Empfehlung, C bzw. C++ zu lernen so stehen lassen kann. Mir gefällt zwar die Entwicklung nicht, aber momentan scheint die ganze Welt auf Sprachen wie Java oder Skriptsprachen wie PHP umsteigen zu wollen (von dem M$-Schrott mal ganz abgesehen). --Bodo Thiesen 01:49, 12. Dez 2004 (UTC)

Diverses

---

Media:Example.mp3$Insertformulahere$Insert non-formatted text here--212.114.180.186 19:15, 8 Jun 2004 (UTC)

---

---

---

wer erklärt mir, was RACECAR ist und wo diese Sprache herkommt resp. eingesetzt wird. Mir ist sie in den letzten Jahrzehnten nicht begegnet (was nicht unbedingt was heissen soll). Scheint mir aber doch eher ein Aussenseiter zu sein - da wüsste ich eine Reihe anderer wichtiger Sprachen wie z.B. PL/1, APL, Fortran, Forth ...

Scriptsprachen

Was mich doch sehr wundert ist, dass Scriptsprachen nicht für große Anwendungen geeignet sind, während Java das scheinbar schon sei. Scriptsprachen werden nicht mehr wie zu Basic-Zeiten Zeile für Zeile interpretiert, sondern wie Java in Bytecode übersetzt. Scheinbar lassen sich hier einige Leute dadurch täuschen, dass man in Java manuell kompilieren muss, und dies in Python und anderen Scriptsprachen automatisch geschieht. Python und Ruby können von den Mitteln, die sie bereitstellen durchaus mit anderen Programmiersprachen konkurieren. Exceptionhandling, Objektorientierung, etc. Eigentlich ist Scriptsprache eine irreführende Bezeichnung für alle Sprachen die mehr können als nur ein Hello World oder etwas Shell Scripting.--Rbb 09:32, 10 Jul 2004 (UTC)

Mich wundert überhaupt die Trennung zwischen Skriptsprachen und nicht Skriptsprachen. Die sinnvollste Definition wäre aber vielleicht, daß eine Skriptsprache als Quelltext gestartet wird, eine nicht Skript sprache vor dem Starten aber "per Hand" übersetzt werden muß. Natürlich hinkt diese Definition, weil man eine Skriptsprache wie BASH durchaus auch kompilieren kann, genauso wie man C Programme durchaus interpretieren kann. Übrigens ist das Übersetzen eines Quelltextes in einen Bytecode, und das Ausführen dieses *keine* Interpretation. (Ok, der Bytecode wird interpretiert, aber nicht das von Programmierer geschriebene z.B. BASIC-Programm). Wir unterscheiden zwischen: Interpretation, Just-in-time Übersetzung, und der "normalen" Übersetzung:

1. Interpretation: Hier wird der Quelltext gelesen, ein Befehl isoliert, analysiert, und dann entsprechend ausgeführt. Hierbei verliert der (statische) Interpretercode nie die Kontrolle. Es wird z.B. kein neuer Maschinencode generiert, dem dann die Kontrolle übergeben wird, der seine Aufgabe erledigt (einen Befehl ausführen) und dann die Kontrolle an den Aufrufer (den Interpreter) zurückgibt.
2. Just-in-time Übersetzung: Das heute fast überall Verwendung findende Konzept im Zusammenhang mit Skriptsprachen: Beim Start des Programmes wird dieses Übersetzt (compiliert), und dieses Compilat dann ausgeführt.
3. "normale" Übersetzung: Hier wird der Quelltext (meist beim Programmierer) übersetzt, und nurnoch das Compilat wird gestartet und somit ausgeführt.

Ein Wort zu Bytecode: Ein Compilat kann entweder Maschinencode sein (der wird dann direkt ausgeführt), oder ein Bytecode (der dann Interpretiert werden muß). Das Konzept des Bytecodes wurde wohl eingeführt, um einerseits die Weitergabe der Quelltexte für ein Programm vermeiden zu können, andererseits das Programm für möglichst viele Plattformen anbieten zu können, ohne dafür extra Arbeit zu investieren (mehrmaliges Übersetzen etc.).

Hmmm, eigentlich könnte man das so auch schon fast von der Diskussionsseite zum Artikel verschieben ...

Ist das neutral genug?

Gruß, Bodo --Bodo Thiesen 03:33, 18 Jul 2004 (UTC)

Skriptsprachen: Lockere Datentypen und einfacher Zugriff auf Systemresourcen.

Programmierung vs. Softwareentwicklung

Wenn Programmierung ein Teilgebiet der Softwareentwicklung ist, warum ist dann die Softwareentwicklung eine Unterabteilung von Programmierung?

Weil hier bei der Übersetzung und Unterscheidung von Software Engineering und Software Construction was schief gegangen ist.

Neutralität

Diese besitzt der bzw. besitzen die Autoren offensichtlich nicht. Ich meine, jeder darf über C denken was er will, diese allerdings als schlecht darzustelen, gar zu behaupten es sei keine Hochsprache, zeugt nicht nur von Unwissenheit, sondern von Ignoranz. Der Autor kann C offensichlich nicht leiden, und glaubt aus diesem Grunde, andere davon abhalten zu müssen, sich mit dieser Sprache überhaupt auseinanderzusetzen. --Bodo Thiesen, irgendwann relativ kurz vor dem Umzug nach de.wikibooks.org

Meiner Meinung nach ist dieser Artikel recht neutral gehalten, C wird dabei auch nicht verunglimpft. Ich denke aber, das einem Einsteiger Zeigerarithmethik (die sehr nahe an Assembler ist) in der heutigen Programmierwelt weniger bringt, als zu Wissen was z.B. ein Objekt ist. C ist schon immer als eine Sprache bekannt gewesen, mit der maschinennah programmiert wird (bzw. wurde) was aber keine Aussage darüber macht ob diese nun gut oder schlecht ist. Ansi C bringt auch wenig an Bibilotheken mit (welche man sich natürlich zusammensuchen kann), aber z.B. bei C++ (das oft als "normales" C missbraucht wird) kann ich mich i.d.R. darauf verlassen das zumindest die STL dabei ist. Offenbar hast du den Artikel auch nicht ganz bis zu Ende gelesen, da dort auch noch erklärt wird warum heute noch in C programmiert wird, was dafür spricht - und ihr dort auch ein Platz gebührt. Wenn du Verbessungen hast, dann lass uns diese doch hier sachlich diskutieren. --Lesath 11:29, 2. Aug 2004 (UTC)

Ich denke mal der obige Kommentar ist schon ein wenig veraltet. Er kommt zum. noch aus der Zeit vor der eigenständigen deutschen Wikibooks-Version. Ausserdem tut sich in letzter Zeit ja einiges hier, insofern denke kann man den Kommentar als erledigt ansehen ;) Gruss --Moolsan 12:35, 2. Aug 2004 (UTC)

Nein, der Kommentar kam aus Wikibook, etwa da, als ich das erst mal was hier geschrieben habe, wol so mitte Juli oder so. Ich denke auch nicht, daß das Thema erledigt ist. Ich habe mir den Teil nicht komplett durchgelesen, aber ich kann schon erkennen, wann objektiv über eine Sprache geschrieben wird, oder wann es eine Hass-Schrift ist. Ich kann auch allerdings beruhigen: Nicht ab »Wählen der Programmiersprache« wird noch existieren, wenn ich mit diesem Buch fertig bin *hr hr hr* (nein im Ernst, ich will das ganze komplett überarbeiten, umstrukturieren, und wesentlich objektiver neu schreiben, und der aktuelle Text enthält nicht viel, was meiner Meinung nach Wert ist, für einen Anfänger da zu stehen). Siehe auch nächsten Abschnitt - #TODO --Bodo Thiesen 03:32, 18. Aug 2004 (UTC)