Diskussion:Programmieren/Archiv2

Das versteht kein Mensch

Das Buch ist nicht schlecht aufgebaut. Aber ohne Begriffserklärung versteht das Buch absolut niemand der nicht sowieso schon programmiert hat. Entweder Ihr weisst darauf hin das das Buch eine Einführung für erfahrene Programmierer anderer Sprachen ist. Oder ihr erklärt am Anfang des Buches die entsprechenden Fachbegriffe.

Ein Teil von Perl

Hallo, wenn ich mir den Teil von Perl "Perl-Programmierung:_Natürliche_und_künstliche_Sprachen" anschaue, so scheint dieser doch hierhin zu gehören (natürlich verallgemeinert). --Bastie 09:03, 20. Mai 2005 (UTC)

TODO

• Das Programmierbeispiel in einer einfachen Programmiersprache realisieren. Dies muß keine real existierende Sprache sein, könnte sogar sinnvoll sein, weil man dann deutsche Begriffe verwenden kann (man bedenke immer: Gerade dieses Buch richtet sich an Personen, die noch nie programmiert haben).
• Die Paradigmen sollten vor den Programmiersprachen abgehandelt werden.
• Nachdem die Paradigmen bekannt sind, sollten alle Programmiersprachen entsprechend eingeordnet werden, und dann mit je einem kurzen Absatz beschrieben werden. Dabei wären vor allem die Dinge zu erwähnen, die die jeweilige Sprachen von den anderen unterscheidet. Wenn überall nur das gleiche steht, kann man es sich auch gleich schenken.
• Der Abschnitt Programmiersprache wählen sollte danach komplett entfernt werden, da durch die Hinweise der vorhergehenden beiden Punkte jeder selber entscheiden können sollte, welchen Weg er gehen will.
• Weiter Programmiersprachen sollten noch Ergänzt werden. Es sollten jeweils auch kurz auf die Vor- und Nachteile eingegangen werden und inwieweit die Sprache für Anfänger geeignet ist.

Gelöschte Kapitel

Ich habe gerade diverse kurze von mir geschriebene Kapitel gelöscht, die von der Einleitung ans Ende geschoben wurden (wo sie nicht mehr passen). Wenn man die Warheit nicht hören will und es unbequem ist, dann bitte. Ich brauche das Buch hier nicht. Sollen die Autoren doch in Schönheit sterben und sich weiter über die beste Programmiersprache streiten.

Wurde inzwischen offensichlich wiederhergestellt. --Bodo Thiesen 01:15, 30. Nov 2004 (UTC)

Programmiersprache wählen wurde gelöscht. Das war aber der interessanteste Teil überhaupt. Warum wurde das gelöscht? Ich bin dafür, die Unterschiede inkl. Vor- und Nachteile von Sprachen hier sehr genau zu beschreiben. Für eine Einzelperson ist dies naturgemäß schwierig, da es schon schwer genug ist, über eine einzelne Programmiersprache den Überblick zu bewahren. Ein Wiki bietet hier aber eine besondere Chance, da sich mehrere Autoren daran beteiligen können. Ich habe auch gesehen, dass einer der letzten Autoren Teile des Java-Textes gelöscht hat. Mir sind die Gründe dafür nicht klar. Vielleicht kann sich der Betreffende in dieser Diskussion dazu äußern. Vorläufig werde ich die Teile wieder einfügen und versuchen mit dem anderen Java-Text zu vereinen. Pro 14:57, 6. Feb 2005 (UTC)

Beim formulieren von Vor- und Nachteilen sollte man vorsichtig sein, wenn es nicht sogar ganz lassen. Ich hab sowas öfters mal in Anfängerbüchern gesehen und das war erbärmlich. An Vor- und Nachteilen gibt es wenig objektives und viel subjektives. Man muss da schon sehr genau aufpassen und seine subjektive Meinung nicht als Fakt hinstellen, wie es leider zu oft getan wird.

Da gebe ich dir natürlich recht. Ich bin aber der Meinung, dass momentan keine Programmiersprache bevorzugt wird. Im Gegensatz zu dem Text, der hier schon stand, halte ich den Abschnitt über Programmiersprachen jetzt für recht ausgeglichen. -- Daniel B 22:29, 6. Feb 2005 (UTC)

Das sehe ich allerdings völlig anders. Beim Formulieren von Vor- und Nachteilen, muss man genau dann vorsichtig sein, wenn man sich nicht sicher ist, und das ist zum Beispiel dann der Fall, wenn man sich nicht auskennt. Wer dazu keine Meinung hat, sollte so ein Buch nicht schreiben.
Und warum soll man sich denn bitteschön als Ziel setzen, keine Programmiersprache zu bevorzugen? Im Gegenteil, wenn eine Programmiersprache Vorteile gegenüber anderen hat, dann muss es genannt werden. Gerade das macht doch ein Buch wertvoll. Ein Text, der sich nicht festlegen will, ist wertlos. Pro 23:12, 6. Feb 2005 (UTC)

Dem widerspreche ich mal. Thema Meinung: Menschen, die mehrere Sprachen verstehen, besonders aus unterschiedlichen Paradigmenecken, neigen meiner Erfahrung nach dazu gar keine einzelne Sprache zu bevorzugen, denn je mehr Sprachen sie kennenlernen, desto mehr Konzepte werden aufgegriffen, desto mehr erkennen sie, dass es keine Sprache gibt, die all die wunderschönen Konzepte vereint. Ich denke dafür gibt es einen guten Grund: bei vielen fortgeschrittenen Konzepten sieht am Anfang nur die eine Seite der Medaille. Ein banales Beispiel sind Exceptions. Als ich die das erste Mal gesehen hab, dachte ich mir coole Idee, genau die richtige Sache um Fehlerbehandlung zu betreiben. (Damals war es noch in das über return codes zu machen - ist es heute ja manchmal immer noch). Tiefer betrachtet sind Exceptions eine Form von goto, welches von sovielen Leuten als schlecht bewertet wird, dass man objektiv sagen kann, das ist schlecht. Viele sind aus dem Grund nicht so richtig glücklich mit den Exceptions. Manche bevorzugen Continuations oder sonstwas, ich bin kein Experte in Sachen Fehlerbehandlung. Wenn man also beide Seiten festhält finde ich das in Ordnung, aber ein Einsteiger wird das kaum verstehen können. Außerdem sind wir hier in einem Wiki, da in einem Artikel seine offensichtlich eigene Meinung zu vertreteten find ich nicht gut. Ein Einsteiger-Tutorial, der sich auf eine einzelne Meinung (die vielleicht noch von ein paar anderen vertreten wird) stützt ist gefährlich.

Abschnitt Effektivität wurde gelöscht. Dies war aber einer der stärksten Abschnitte überhaupt, zumal - im Gegensatz zu den anderen Teilen - anscheinend von jemandem geschrieben, der Programmierung aus der beruflichen Praxis kennt. Habe den Abschnitt erst mal wieder eingefügt. Für weiteres Vorgehen müssen wir uns abstimmen. Pro 15:51, 6. Feb 2005 (UTC)

Warum hast du den Abschnitt Effekivität wieder hergestellt? Alles was hier drinsteht, steht so auch in den Übrigen Abschnitten, allerdings NPoV und ohne Meinung und Gegenmeinung. Sieh mal im Archiv nach, dort wurde bereits viel über den Abschnitt diskutiert. Ich zumindest bin jetzt nicht bereit die ganze Diskussion wieder neu aufzurollen. Hab die Änderungen deshalb wieder rückgängig gemacht. -- Daniel B 16:02, 6. Feb 2005 (UTC)

Daniel, wir müssen hier nicht so sehr auf Neutralität bedacht sein, wie in Wikipedia. Das ist ein ganz wesentlicher Unterschied zur Wikipedia: In Büchern dürfen auch Meinungen vertreten sein.
Ich verstehe, dass das Wiederaufrollen des Themas lästig ist, finde aber, wenn sich neue Aspekte ergeben, muss man darauf eingehen. Der Abschnitt "Effektivität" war der beste dieses Buches überhaupt. Zu allem Übel schreibt der Autor, der ihn verfasst hat, nicht mehr für dieses Projekt. Ich finde zwar, er hat übertrieben reagiert, als er sich nach dem Umbau von der Arbeit an diesem Buch abgewandt hat (denn man kann ja über alles reden), aber so sieht es erst mal aus. Das ist fatal, denn der hatte Ahnung. Das große Problem dieses Projektes und das anderer ist ein Autorenproblem. Es fehlt an kompetenten, erfahrenen Autoren. Pro 23:47, 6. Feb 2005 (UTC)

Thema Effektivität: Effektivität wovon? Offensichtlich läuft es auf die Empfehlung zu Architektur, Prozessauswahl und Sprachwahl für SW-Entwicklungen hinaus. Der Hobbyist kann hier freiheitlicher entscheiden. Die Ein-Mann-Firma unterliegt leicht höheren Einschränkungen, z.B. durch Kundenvorgaben, die im Requírement Engineering festgehalten werden und in Projektspezifikationen und einem Pflichtenheft dokumentiert werden sollten. Aber auch Ein-Mann-Firmen können unprofessionell arbeiten, obwohl dies der Beruf ist.

Geeignete Maße die in eine Effektivität reinspielen, sind monetäre und non-monetäre, objektive Kosten jeglicher Art, die sich aufschlüsseln lassen. Dies könnte man hier tuen.

Dass je größer ein Projekt, je mehr Beteiligte, desto weniger Entscheidungen könne man selbst treffen, ist inkorrekt... Die jeweiligen Entscheidungsarten sind an klassische Rollen wie z.B. die des SW-Architect gebunden. Hat man diese Rolle, so darf man die zugehörige Entscheidung treffen.

Über Herren, Reibung und Bürokratie zu schreiben, ist hier irreführend.

"Professionelle Software-Entwicklung" besteht aus mehr als dem puristischen Code-Schreiben. Dies ist ebenfalls nur eine einzige winzige Rolle im SW-Development. Dies lässt sich klassisch neutral beschreiben.

Kunststückchen, wie mit untauglichen Mitteln und unter externen Zwängen doch noch ein brauchbares Ergebnis zu erzielen und dadurch den Job zu behalten, sind keine objektiven Einflussfaktoren für ein Maß der Effektivität. Wieder aber: Effektivität wovon?

Über das Modell des Entwicklungsprozesses und der Pflege eines Produktzyklus und einer Dokumentation und und und... kann eine Qualitätssicherung erfolgen. Je nachdem wovon eine Effektvität bestimmt werden soll, spielen diese Faktoren hinein oder auch nicht.

Gemeint ist hier aber offensichtlich nicht eine Kostenfunktion, die den Aufwand zum Ausdruck eines Algorithmus bestimmter informationstechnischer Komplexität oder Ordnung in einer konkreten Sprache beschreibt, oder?

Ich kann sehr gut verstehen, dass Daniel den Text für fachlich fragwürdig hielt und einen NPoV verletzt sieht. Er ist nicht objektiv und führt keine geeigneten Maße und Definitionen heran, die ein Maß für Effektivität (wovon eigentlich) rechtfertigen und veranschaulichen.

Der NPoV kann eingehalten werden. Und es kann fachlich korrekt wiedergegeben werden, ohne persönlich gefärbte subjektive Texte hierbei zu benutzen. Der schwammige Umgang mit dem Begriff der Effektivität ohne klare Definition und Nachvollziehbarkeit anhand geeigneter Maße (oder Referenzen) macht den Text unglaubwürdig. --Oliver Merkel 00:33, 7. Feb 2005 (UTC)

Der erste Abschnitt handelt eigentlich großteils vom Vergleich zwischen Hochsprachenprogrammierung und Assemblerprogrammierung. Das ganze ist weiter unten bereits erwähnt, ohne allerdings ein Eindruck zu erwecken, es gäbe heute noch eine Diskussion darüber, ob es besser sein in Assembler oder in einer Hochsprache zu programmieren. Niemand wird heute noch ein größeres Programm in Assembler schreiben! Das kann man wirklich in einem Satz abhandeln. Nicht einmal ein Betriebssystem wird heute noch in Assembler entwickelt. (Insofern verstehe ich nicht ganz, warum du denkst, dass der Abschnitt einer der besten überhaupt sei).

Noch mal zum NPoV: Auch hier ist der NPoV sehr wichtig, was man am Sprachenstreit sieht (siehe Archiv). Der eine ist der Meinung, Java sein die beste Sprache und schreibt das rein. Der andere findet C# viel besser und ändert den Abschnitt wieder um, der dritte findet C++ am Besten usw. Wenn ein Sprache bevorzugt wird, kommt es schnell wieder zum Streit. Deshalb ist es auch hier wichtig von einem neutralen Standpunkt aus zu schreiben. Es gibt eben nicht die Sprache die am Besten ist, sondern sich für ein Aufgabenstellung besser für die andere schlechter eignet. Das sollte auch so rüberkommen. -- Daniel B 09:43, 7. Feb 2005 (UTC)

Oliver, wenn ein Text fachlich fragwürdig ist, heißt das nicht, dass die Neutralität verletzt ist. Das sind zwei verschiedene Paar Schuhe.
Zwar halte ich einige der inhaltlichen Einwände für berechtigt, aber den Vorwurf mangelnder Neutralität kann ich nicht nachvollziehen. Daniel, könntest du nochmal auf den Punkt bringen, an welcher Stelle du das siehst (falls du es so siehst)?
Ich habe mir das Archiv zum Thema "Sprachenstreit" noch einmal angesehen. Dort hat sich Bodo zu dem Thema geäußert. Ich muss sagen, ein paar Statements hätte ich auch rausgeschmissen, insgesamt halte ich aber Bodos Darstellung für überzogen.
Daniel, um einer Auseinandersetzung zu den Sprachen aus dem Weg zu gehen, verzichtest du auf eine Beurteilung? Das kann es doch wohl nicht sein. Wenn es Uneinigkeit zu einem Thema gibt, müssen die Meinungen genauer aufgeschlüsselt werden. Dafür gibt es ja diese Diskussionsseite. Auch hierbei sehe ich aber die Ursache für Meinungsverschiedenheiten gar nicht so sehr in fehlender Bereitschaft zur Neutralität, sondern oft einfach in mangelndem Verständnis oder unvollständigem Wissen über das jeweils andere Schwerpunktgebiet.
Auch eine Aussage wie "Es gibt eben nicht die Sprache die am Besten ist" muss bitte begründet werden. Warum soll es die nicht geben? Welches Naturgesetz sollte dafür verantwortlich sein? Wenn je nach Aufgabenstellung die eine oder andere Sprache zu bevorzugen sei, dann zeige bitte auf, welches diese Aufgabenstellungen für welche Sprache sein sollen. Die Sichtweise mit der speziellen Sprache, die je nach Problemfeld auszuwählen sei, war übrigens eine Sichtweise die man in den Siebzigern und Achtzigern häufig hören konnte. Damals sahen die Sprachen aber auch noch anders aus, heute tendieren sie dagegen zu Generalisten. --Pro 15:16, 8. Feb 2005 (UTC)

Pro :-), mittlerweile vermute ich, es geht Dir hier um etwas anderes? Das mit Deinen 2 verschiedenen Paar Schuhen (was sich da für tolle Kombinationen ergeben ... :-))) ist wohl wahr. Deswegen ja auch: Neutrale Wiedergabe von Argumenten bei nachvollziehbarer Darstellung wäre bei NPoV schon sinnvoll. Jetzt beachte man das 'und'! Davon gibt es oben einige! Neutrale Wiedergabe 'und' Nachvollziehbarkeit durch fachlich korrekte Darstellung (2 verschiedene Paar doppelete Schuhe die aber voneinander abhängig sind...). Stand auch schon oben. Da gibt es also 2 Aussagen, die man mit einer logischen Verknüpfung verwurstet. Hier halt ein 'und'. Also nicht Oder, Exlusiv-Oder oder irgendwas anderes. Wenn das durch Dich nicht nachvollzogen werden kann, freut es mich um so mehr, dass einige der inhaltlichen Einwände vielleicht berechtigt erscheinen und hoffentlich zur Verbesserung des Textes beitragen werden.

Aber nochmal anders umgangssprachlicher ausgedrückt: Das neutralste Geblubber bringt nichts, ist aber neutral, wenn es keiner nachvollziehbaren Notion der fachlich korrekten Darstellung folgt. Deswegen bedingt das eine das andere... Da stimmst Du doch wohl bei einem Lehrbuch zu, oder?

Die Auseinandersetzung zu den Sprachen sollte nicht durch den Verzicht eines Vergleichs wegfallen. Da stimme ich Pro zu. Jedoch ist die Frage, was vernünftige Maße für einen Vergleich sind. Daher die Frage oben:

Gemeint ist hier aber offensichtlich nicht eine Kostenfunktion, die den Aufwand zum Ausdruck eines Algorithmus (in einer bestimmten Sprache) bestimmter informationstechnischer Komplexität oder Ordnung in einer konkreten Sprache beschreibt, oder?

Wenn man solch eine Kostenfunktion einführt und beschreibt, hat man ein solches (objektives, NPoV, nachvollziehbares) Maß ohne, dass jemand begründet: Die schönere Sprache gewinnt. Und der Nächste findet etwas anderes schön. So war es gemeint :-) und nicht anders. --Oliver Merkel 17:35, 8. Feb 2005 (UTC)

Ja, inhaltlich bringt uns dein Beitrag weiter. :-) Nur: Dies ist die Diskussionsseite. Schreib doch etwas dazu im "Kapitel"! Das ist besser als ersatzlos streichen. Der Vorgängerbeitrag ist trotz einiger Schwächen - auf Grund der erwähnten Praxisnähe - interessant. Software Engineering ist ja auch eine relativ junge Disziplin, und dass noch nicht alles in jeder Softwareschmiede optimal umgesetzt wird, zu erwarten - auch ein interessanter Aspekt, oder? Und unter den von dem Autor erwähnten "untauglichen Mitteln" stelle ich mir z.B. mit Bugs durchsetzte Programmierwerkzeuge vor. Das ist leider Realität und es stimmt ferner, dass man nicht immer die Wahl hat, z.B. weil es einfach keine Alternative gibt. --Pro 19:05, 9. Feb 2005 (UTC)

Äh? Das mit der Kostenfunktion verstehe ich nicht. Ist vielleicht nicht mein Niveau.

Oliver meint eine "Metrik" zum Vergleich der verschiedenen Sprachen (genauer gesagt, glaube ich, dass Oliver das meint :-)) ... Leute, ich muss gerade weg ... Fortsetzung folgt ... --Pro 19:05, 9. Feb 2005 (UTC)

Na dann viel Spaß beim Finden von so einer Metrik. Hieße sowas nicht eher Nutzenfunktion als Kostenfunktion? Wie will man denn sowas aufstellen? Ich denke, dass sich weder die Kompetenz hier findet, um so etwas aufzustellen, noch dass so etwas überhaupt gut geht. Aber auf jeden Fall ist die Kompetenz nicht da :-) Sowas ist ja, milde ausgedrückt, ein nicht-triviales Problem.

Das wird in jeder Veröffentlichung gemacht, die ernstzunehmende Vergleiche über ein Themengebiet durchführt. Warum auch immer dies 'nicht trivial' sein soll, wenn man diese 'Metrik' selbst definieren darf. Es ist eher ein Mangel halbgar vor sich hin zu schreiben und eine Sprache gänzlich oder in bestimmten Anwendungsfällen zu favorisieren, weil sie 'schöner' ist oder man dazu 'besser geeignet' sagt. Die Kompetenz ist sicherlich vorhanden, sobald hier jemand auch nur einen Funken von Kenntnis zum Themengebiet besitzt. Ob die Kompetenz da ist, es neutral und fachlich korrekt auszudrücken, mag etwas anderes sein. Metrik ist halt allgemein. Kosten sollten minimiert sein. Stellt man es als Nutzenfunktion dar, wird dieser wohl eher maximiert. Nennt man es Aufwand, so soll dieser wieder klein (minimiert) sein. Nennt es, wie ihr wollt. Ernst zu nehmen sind solche Aussagen über Effektivität nur, wenn genannt ist, wie das Maß (Effektivität ?) definiert ist und was dieses Maß umfasst. Als nächstes sollten alle betrachteten Programmiersprachen theoretisch in Parametern dieser Funktion ausgedrückt werden können. Ob das Zahlenwerte, Koeffizienten oder schwammige undefinierte Bereiche ala 'Wolken' in einem Raum sind oder irgendwo am Anfang, in der Mitte oder am Ende einer begrenzten Skala, ist wurscht. Nur muss im Raum, der durch die Parameter aufgespannt wird, diese Programmiersprache platzierbar sein. Erst dann sind Trade-Offs zwischen abhängigen Parametern vernünftig beschreibbar und man kann erklären wo eine ideale Sprache im Parameterraum angesiedelt wäre, warum es eine solche nicht gibt und geben kann und warum mehrere Sprachen hier ihre Daseinsberechtigung haben.

Ein Wikibook ist übrigens geduldig... Man kann nachträglich die Anzahl der Parameter erweitern. Dadurch die Komplexität einer solchen Funktion und der Argumentation steigern. Es wäre also problemlos, selbst wenn das erste Maß einfach zum Beispiel die Kosten der verbreitetsten Entwicklungsumgebung der Sprache und die Anschaffungskosten des RTE darstellt. Und ein anderer Autor als weiteren Parameter die Laufzeit eines standardisierten Benchmarkings verwendet, falls noch keiner auf die Idee kam. Der Nächste kommt mit einem 'Erfolg eines Reverse Engineerings aus der Binärdarstellung, bzw. Bytecode oder interpretierten Codes je nach Sprache'. Daraus werden Problematiken klar, wenn man dann die Sprachen darin positioniert. Metrik oder Maß bedeutet nicht zwingend, dass eine eindeutige Zahl daraus errechnet werden muss. Auch kann so klar gemacht werden, warum unterschiedliche Softwareprojekte (sowohl im Hobbybereich wie im professionellen Bereich) in disjunkten Räumen eines solchen Parameterraums liegen.

Da kann mir wirklich keiner weiß machen, dass es für viele Kenner des Themenbereichs unbegründbar ist, warum die Welt nicht so häufig ABAP oder VHDL spricht und Java und PHP populärer ist... Oder dass Ruby oder Gambas noch nicht so viele Anhänger hat wie C, Fortran, Visual Basic oder Pascal. Mindestens einen halbgaren Parameter kann man da bestimmt nennen. Und eben aus diesen Parametern lässt sich eine Gesamtfunktion ala Kosten oder Nutzen oder Aufwand beschreiben. Selbst wenn Koeffizienten eventuell gar nicht exakt bestimmbar sind. Wenn mal wieder Zeit besteht, kann ich gerne so etwas mal anfangen, falls es bis dahin noch kein anderer angeht. Wie Pro schon schreibt... demnächst vielleicht im Kapitel... Nur muss es im Kapitel ein klein wenig (aber nicht viel) durchdachter und weniger salopp ausgedrückt sein als hier. --Oliver Merkel 23:27, 10. Feb 2005 (UTC)

Das hat mich nicht überzeugt. Eine beliebige Metrik aufstellen kann jeder Depp. Es geht gerade darum, dass sie neutral und kompetent ist. Was nützt eine Metrik, die das nicht ist? Außerdem ist das hier ein Buch für Einsteiger. Wäre es nicht geschickter, die indirekte Schiene zu wählen und dem Leser das nötige Verständnis beizubringen um selbst entscheiden zu können? Hat jemand überhaupt schonmal solch eine Metrik gesehen? Ich lehne mich jetzt mal aus dem Fenster und sage, jede Metrik wird soviele Defizite haben, dass sie unbrauchbar ist. Und ich meine wirklich jede Art von Defizite. Es sind viel zu viele Faktoren die man berücksichtigen müsste. Das wird mindestens unverständlich. Meine Meinung. Nichtsdestotrotz bin ich gespannt was hier dabei rauskommt, wenn denn überhaupt was rauskommen sollte. Ich lass mich gerne eines Besseren belehren. Auch wenn ich immer noch der Meinung bin, dass das hier nicht der richtige Platz für sowas ist.

1. > Hieße sowas nicht eher Nutzenfunktion als Kostenfunktion?

Erstens orientiert sich in der Wirtschaft der Nutzen am Gewinn, also an den Kosten. Oder um welchen Nutzen sollte es sonst gehen?

Zweitens wird der Begriff "Kostenfunktion" häufig auch abstrakt verwendet, und zwar für alle Arten von Optimierungsproblemen, auch wenn es im Einzelfall nicht zwingend um Kosten geht.

Was nützt mir die und die Sprache? Sowas frage ich mich eher als, was mich eine Sprache kostet. Das war mein Gedanke. Aber danke, dass Du mich aufgeklärt hast, bei den Optimierungsproblemen. Hatte ich doch glatt vergessen. Spaß beiseite. Dies ist ein Buch für Einsteiger, dachte ich. Deswegen mein bescheidener Vorschlag, weil ich es so verständlicher fände.

2. > Wäre es nicht geschickter, die indirekte Schiene zu wählen und dem Leser das nötige Verständnis beizubringen um selbst entscheiden zu können?

Wie soll man jemandem ein Verständnis beibringen, das man selber nicht hat? Einen Leser soweit zu bringen, dass er die Entscheidungen selber fällen kann, erfordert nicht weniger, als sich das selber klar zu machen. --Pro 16:56, 13. Feb 2005 (UTC)

Daraus schließe ich, dass Du erst eine Metrik brauchst um Dir klar zu werden, welche Sprache Du bevorzugst. Außerdem ist das soweit ich weiß ein bei den Psychologen bekanntes Phänomen. Indirekt Wissen zu vermitteln ist manchmal einfacher. Ich steige aber an dieser Stelle aus der Diskussion aus. Viel Spaß noch mit Eurer Metrik.

Was heißt nun wieder Auseinandersetzung von verschiedenen Sprachen. Es werden Pro- und Contraargumente jeder Sprache aufgeführt, aber das Buch soll keine bestimmte bevorzugen. Es gibt einfach nicht die beste Sprache! Da hilft auch keine Diskussion oder ein Aufschlüsseln von Meinungen. Nochmals: Jede Sprache har ihre Vor- und Nachteile und jeder Programmierer bevorzugt eine andere Sprache. Wie willst du dies unter einen Hut bringen, in einem Projekt, in dem kooperativ Bücher geschrieben werden? Dies geht nur wenn du keine Sprache bevorzugst.

Wenn es ein beste Sprache gäbe, warum werden dann Betriebssysteme auch heute noch in C geschrieben (Linux, Windows) ? Warum wird Assembler für umfangreichere Projekte praktisch nicht mehr eingesetzt? Warum werden in Prolog keine Computerspiele entwickelt? Warum werden in Java keine Programme entwickelt, die direkt auf die Hardware zugreifen? Also diese Fragen beantwortetest du mir jetzt bitte, wenn du der Meinung bist, dass es die ein Sprache gibt, die für alle Anwendungsfelder gleichermaßen geeignet ist. -- Daniel B 20:16, 8. Feb 2005 (UTC)

Aus dem Umstand, dass eine Sprache nicht für alle Anwendungsfelder gleichermaßen geeignet ist, kannst du nicht folgern, dass sie es nicht für bestimmte Anwendungsfelder ist, und auch nicht, dass sie es nicht für den überwiegenden Teil von Anwendungsfeldern ist. Das beste Beispiel lieferst du doch selbst: Warum werden Betriebssysteme auch heute noch in C geschrieben? - Weil es dafür handfeste Gründe gibt. Was wird denn statt Assembler häufig eingesetzt? In welcher Sprache - statt Prolog - werden denn Computerspiele entwickelt? In welcher Sprache - statt Java - werden denn Programme entwickelt, die direkt auf die Hardware zugreifen? Bitte Antwort ankreuzen:

[ ] A

[ ] B

[ ] C

--Pro 16:56, 13. Feb 2005 (UTC)

Du wolltest eine Begründung für die Aussage "es gibt keine beste Sprache". Da es keine Sprache gibt, die für alle Anwendungsfelder gleichermaßen gut geeignet ist, gibt es auch keine beste Sprache. Und damit kann es auch keine Empfehlung für eine bestimmte Sprache geben. Das sollten die Beispiele zeigen. -- Daniel B 17:15, 13. Feb 2005 (UTC)

Nach der Logik gäbe es dann aber auch keinen Sieger im Zehnkampf, wenn die Voraussetzung dafür der Sieg in jeder Einzeldisziplin wäre. Ich bin für Aufschlüsselung in Problemkategorien. --Pro 17:28, 13. Feb 2005 (UTC)

Und wie sollten diese Problemkategorien aussehen? -- Daniel B 17:41, 13. Feb 2005 (UTC)

Bei den Beschreibungen zu den einzelnen Programmiersprachen wurde schon einiges genannt. Da sollten wir erst mal weitermachen. Alles andere später. Pro 19:24, 14. Feb 2005 (UTC)

Daniels Logik hat mit (der Bewertung im) Zehnkampf nix zu tun. Die Wertung dort erfolgt nach vorgegebenen Regeln. Ein Mensch, wahrscheinlich mehrere, hat sich das ausgedacht. Sowohl den Zehnkampf an sich, als auch die Wertung. Die Erfindung oder besser gesagt Zusammenenstellung der Disziplinen ist ganz genauso eine Erfindung, wie die der Wertungsregeln. Man hätte die auch anders machen können, einfach so. Ich brauche glaube ich nicht erwähnen, dass das bei einer Metrik nicht der Fall sein sollte. Sowas wohnt der jeweiligen Sprache inne und irgendwie muss man es ausdrücken. Wenn jemand daher kommt und sagt, die Punkteverteilung im Zehnkampf ist unfair, weil die und die Disziplin ist doch viel besser/mehr Wert usw... man sollte das nach Bewertungskriterien machen, die die Anforderungen an den Athleten aufschlüsseln. So einen erklärt man für verrückt. Ein Bewertungssystem für Programmiersprachen sollte noch eine Stufe komplexer werden.

Dem stimme ich zu. Man kann sogar ohne Einschränkung auf ein konkretes Anwendungsgebiet argumentieren indem man imperatives dem funktionalen gegenüberstellt. Bis heute ist es niemandem gelungen eine große Vereinheitlichung der beiden Paradigmen zu finden. Vielleicht gibt es sie gar nicht. Wer sagt, das eine ist besser als das andere (alles in seiner heutigen Realisierung, versteht sich), sollte sich nochmal grundlegend Gedanken darüber machen, ob er nicht doch lieber was anderes als programmieren möchte.

Java

Nachdem ich den Abschnitt zu Java überarbeitet habe, sind doch einige Dinge rausgeflogen. Begründung: Größtenteils handelt es sich dabei um Beschreibungen der Plattform Java. Hier geht es aber um die Programmiersprache Java. Ich bin gar nicht der Meinung, dass die darin aufgestellten Behauptungen alle falsch sind, aber hier passen sie meiner Meinung nach nicht rein.

Die entfernten Teile:

Die Anwendungen werden zudem auf einer virtuellen Maschine ausgeführt, die es für eine große Anzahl an Betriebssystemen und Rechnerarchitekturen gibt.

Der Java-Quellcode wird vom Compiler zunächst in einen maschinenunabhängigen Zwischencode (den sog. Bytecode) übersetzt.

Auf dem Zielrechner wird der Bytecode dann von einer Laufzeitumgebung (der Java Virtual Machine) in den Maschinencode der konkreten Plattform übersetzt und ausgeführt. Inzwischen sind für die meisten verfügbaren Betriebssysteme und Rechnerarchitekturen passende Laufzeitumgebungen verfügbar.

Den Durchbruch erlebte Java, als sich Netscape entschied, die Sprache in ihren Webbrowser Netscape Navigator zu integrieren. Dadurch wurde es möglich, in HTML-Seiten integrierte Programme, so genannte Applets, direkt vom Webbrowser ausführen zu lassen.

Sun hat Java inzwischen in mehrere, teilweise voneinander unabhängige Zweige für verschiedene Einsatzbereiche aufgeteilt. Neben der Standard Edition existiert eine Enterprise Edition, die hauptsächlich für die Programmierung von Serverkomponenten konzipiert wurde. Die Mobile Edition zielt auf Geräte mit beschränkten CPU- und Speicherkapazitäten ab (Handhelds, Handys, etc) und stellt eine stark abgespeckte Variante der Standard Edition dar.

Ein Vorteil dieser Sprache besteht darin, dass Java-Programme prinzipiell ohne Änderung auf allen unterstützten Betriebssystemen laufähig sind.

Nachteilig wirkt sich die fehlende Möglichkeit hardwarenaher Programmierung aus. Hier muss auf Sprachen wie beispielsweise C oder C++ zurückgegriffen werden.

Pro 15:22, 6. Feb 2005 (UTC)

Da sehe ich jetzt nicht ganz wo das Problem bei den entfernten Abschnitten liegt (abgesehen von der Dopplung bei der Virtuellen Maschine, die bereits weiter oben erwähnt wurde). Dieses Buch ist für Anfänger gedacht, die sich einen Überblick über die verschiedenen Sprachen machen wollen um ihnen die Entscheidung zu erleichtern was sie lernen wollen. IMHO kann man die Plattform nicht so einfach von der eigentlichen Sprache trennen. Beispielsweise hast du den Abschnitt über die Applets rausgeschmissen: Applets waren zu Beginn (heute vielleicht weniger) ein sehr wichtiger Bestandteil der Sprache und haben Java schließlich erst zum Durchbruch verholfen. Mir ist nicht klar, warum dies nicht erwähnt werden soll. Das gleiche gilt für Abgrenzungen zu anderen Sprachen. Ein wichtiger Aspekt von Java ist dabei, dass man nicht hardwarenah damit programmieren kann. -- Daniel B 15:44, 6. Feb 2005 (UTC)

1. Einverstanden, was die hardwarenahe Programmierung betrifft (füge ich wieder ein). 2. Applets finde ich für Anfänger ein zu spezielles Thema, aber von mir aus kann es rein. Dennoch ist doch das Thema hier der Sprachvergleich und nicht, mit welchen Sonderfeatures jedes Teil daherkommt. Dass Applets in einem Javabuch behandelt werden ist klar, aber nicht unbedingt in einem allgemeinen Programmierbuch. 3. Wirklich daneben ist aber die Durchmischung von Sprache und Plattform. Von mir aus können wir auch etwas zur Plattform reinbringen, aber gerade für Anfänger muss der Unterschied sehr genau erklärt werden. Wenn wir bei Java etwas zur Plattform bringen, dann bitte auch etwas bei den anderen Sprachen. Und vorläufig bleibe ich dabei, dass "Informationen" wie "Sun hat Java inzwischen in mehrere, teilweise voneinander unabhängige Zweige für verschiedene Einsatzbereiche aufgeteilt. Neben der Standard Edition existiert eine Enterprise Edition, die hauptsächlich für die Programmierung von Serverkomponenten konzipiert wurde. Die Mobile Edition zielt auf Geräte mit beschränkten CPU- und Speicherkapazitäten ab (Handhelds, Handys, etc) und stellt eine stark abgespeckte Variante der Standard Edition dar. " zumindest an dieser Stelle für einen Anfänger völlig deplatziert sind. Pro 18:15, 6. Feb 2005 (UTC)

Den letztgenannten Abschnitt kannst du meinetwegen rausnehmen. Das Argument, dass dies dann auch bei anderen Sprachen genannt werden müsste halte ich durchaus für nachvollziehbar. -- Daniel B 18:25, 6. Feb 2005 (UTC)

Ja, aber vor allem ist es an der Zeit, mit dem Mythos der Plattformunabhängigkeit aufzuräumen. Dass so viele an die Java-Plattformunabhängigkeit glauben, ist Ergebnis eines hervorragenden Marketings. Was bedeutet denn überhaupt "Plattformunabhängigkeit"? In Wirklichkeit ist es ein ziemlich verwaschener Begriff, und es wäre eine interessante Aufgabe für dieses Projekt, einmal etwas Klarheit dort hineinzutragen. Nur ein Beispiel: C ist für weit mehr Plattformen verfügbar als Java. Wie kann Java dann plattformunabhängiger sein? Pro 23:33, 6. Feb 2005 (UTC)

Soweit ich weiß, wird bei Java in Bezug auf Plattformunabhängigkeit von "Compile once, run anywhere" oder so gesprochen. Das trifft meist zu. Was die Verfügbarkeit von Java angeht, auf welchen Platformen läuft denn alles der GJC aus der Gnu Compiler Collection? Darauf trifft der Slogan zwar nicht mehr zu, aber der trifft bei C ja auch nicht zu. Auf die Anzahl an Platformen kommt es auch nicht an. Eher auf die damit verbundene Nutzeranzahl. Mal ganz pragmatisch, was nützt mir ein C Compiler für Platform X, wenn es da 100 User gibt. Ist es nicht eher von Bedeutung wenn ich mit meinem einmal kompilierten Programm zwischen den am meisten benutzten Platformen hin- und herhüpfen kann?

> Soweit ich weiß, wird bei Java in Bezug auf Plattformunabhängigkeit von "Compile once, run anywhere" oder so gesprochen.

Das ist genau das, was ich sage: ein Marketingspruch, und du bist darauf reingefallen. Eine etwas umfassendere Definition zu Plattformunabhängigkeit befindet sich unter Wikipedia:Plattformunabhängigkeit.
Als leidgeprüfter Java-Programmierer kann ich dir versichern, dass es damit nicht getan ist. Es gibt VMs unterschiedlicher Hersteller, mit jeweils unterschiedlichen unterstützten Features, innerhalb der Hersteller unterschiedliche Versionen mit unterschiedlichen Features aber auch unterschiedlichen Bugs, noch dazu gibt es die Abhängigkeit von der Betriebssystemplattform, auf der die VM läuft. Und versuch doch mal, ein Programm, das Swing verwendet, auf einer VM ohne Grafikausgabe einzusetzen.

Hmm, da bin ich jetzt ein bischen baff. Absolute Plattformunabhänigkeit immer und überall kann es nicht geben, unmöglich. Ein grafisches System (z.B. Swing) kann nur arbeiten, wenn Grafik da ist. Aber das hat gar nix mit dem Thema zu tun. Man kann jedes erdenkliche System kastrieren und sich ein Programm ausdenken, was dann da nicht läuft. Spalten und dann nörgeln kann man immer. Bei Java hat man mehr Plattformunabhängigkeit umsonst, als bei bei Deinem Beispiel C. Wenn die VMs nicht alles unterstützen ist das ein Problem; aber nicht eins, das der Java Plattform innewohnt. Was nützt mir ein C-Compiler für ein System, für das es meine verwendeten Bibliotheken nicht gibt? Das ist überall das gleiche. P.S.: der Wikipedia-Artikel widerspricht sich selber schon im ersten Satz der Aufzählung. Quellcode-Portabilität: Diese Form der Plattformunabhängigkeit ist häufig bei C-Programmen für UNIX anzutreffen Nur für UNIX? Tolle Portabilität.

> Auf die Anzahl an Platformen kommt es auch nicht an. Eher auf die damit verbundene Nutzeranzahl. Mal ganz pragmatisch, was nützt mir ein C Compiler für Platform X, wenn es da 100 User gibt.

Doch, natürlich kommt es darauf an. Was nützt mir eine VM für Plattform X, wenn ich eigentlich eine für Plattform Y brauche? Für praktisch jeden neuen Prozessor gibt es einen C-Compiler. Da kann Java nicht mithalten. --Pro 16:41, 8. Feb 2005 (UTC)

Da widersprichst Du Dir selber. Was nützt mir nen C-Compiler für irgendeinen Prozessor? Ich habe größere Programme im Sinn, die nicht nur auf die C Standardbibliotheken zurückgreifen. Und die sind winzig gegenüber der Java API. Aber ich denke, ich hör hier auf. Die Argumentation wird langsam schwach. Im allgemeinen frage ich mich gerade, warum wir hier darüber diskutieren...

Da kann ich nur voll zustimmen. Was bringt dir ein C-Compiler auf Plattform xyz, wenn du ein Programm unter Windows, Linux und Solaris veröffentlichen willst? -- Daniel B 20:36, 8. Feb 2005 (UTC)

Ich find die These, dass Applets Java erst zum Durchbruch verholfen haben, etwas gewagt. Was Java zum Durchbruch verholfen hat ist die Toolunterstützung und die kam nicht, weil's Applets gibt, sondern vorwiegend, weil die Sprache so simpel ist. (Warum gibt es wohl kaum vernünftige IDEs für C++?) Aber das ist auch nur *eine* Meinung, und deswegen sollten solche Statements überhaupt nicht rein.

Also Anfangs hatte Sun mit Java (bzw. damals noch Oak) keinerlei erfolgt. Der kam er mit Einbindung von Java in den Netscape Navigator. IMHO kann man deshalb schon von einem Durchbruch sprechen. -- Daniel B 22:29, 6. Feb 2005 (UTC)

Darin, dass die gute Toolunterstützung mit der Einfachheit der Grammatik zu tun hat, stimme ich überein, nicht aber darin, dass die Toolunterstützung ausschlaggebender Faktor für die Ausbreitung war. Wie dem auch sei, der Punkt ist meiner Meinung nach irrelevant für dieses Buch. Sowas muss ins Java-Buch, aber nicht in diese Synopse. Pro 23:23, 6. Feb 2005 (UTC)

Jetzt stellt sich die Frage was eigentlich Druchbruch heißt, aber ich lass es gut sein. Mit "weil die Sprache so simpel ist" meinte ich allerdings nicht die Einfachheit der Grammatik, die ist nicht einfach, aber darum geht es auch nicht wirklich. Ich meinte vielmehr, dass Java als neue Sprache relativ arm an Features ist (viele unsinnige Sachen aus C++ weggelassen, aber so gut wie keine fortschrittlichen Konzepte aufgenommen) und die Bytecode-Erzeugung vom Compiler kaum optimiert wird (werden braucht?), die VM macht da ja das meiste.

Doch, die Grammatik von Java ist um Größenordnungen einfacher als die von C++, und das ist auch der Grund für die stark vereinfachte Toolunterstützung bei Java.
Dass im Hinblick auf die Zwischencode-Erzeugung nicht optimiert werden muss, ist falsch. Beide Compilerphasen müssen optimieren. Das Ergebnis siehst du bei .NET: Die mit dem C++-Compiler erzeugten Programme sind schneller, und zwar genau aus dem genannten Grund. --Pro 16:55, 8. Feb 2005 (UTC)

Java Grammatik einfacher als C++, ja. Aber es ist schwer eine schlimmere Grammatik als C++ zu finden. Deine Argumentation bei der Optimierung verstehe ich nicht. Warum müssen (beide optimieren)? Müssen tut keiner :) Außerdem sprach ich von kaum und nicht von gar nicht optimieren. Inlining macht die VM, nicht der Compiler. Garbage Collection passiert in der VM. Das sind die beiden naheliegendsten Sachen. Zur Laufzeit kann das alles effektiver erledigt werden, deswegen braucht der Compiler auch weniger optimieren. Und was hat Java mit dem C++-Compiler von .NET zu tun?

Zur Optimierung: Wenn das Gesamtergebnis optimiert sein soll, müssen beide Teiloptimierungen durchgeführt werden; und anstatt das einfach nur als Behauptung in die Welt zu setzen, habe ich einen Beleg in Form eines Anwendungsfalls beigefügt, und zwar die .NET-Plattform mit ihren verschiedenen Sprachen. Ebenso wie Java erzeugen nämlich die .NET-Sprachen (zu denen übrigens auch das Java-Derivat J# gehört) Zwischencode. Der Unterschied zwischen den verschiedenen .NET-Sprachen ist messbar (!) (Metrik!!) --Pro 17:15, 13. Feb 2005 (UTC)

Sag mal, diskutierst Du nur um zu diskutieren? Lies Dir mal durch worum es eigentlich geht. Es *brauchen* in einem Java->Bytecode Compiler kaum Optimierungen vorgenommen zu werden. *Deswegen* ist es relativ einfach einen anständigen Compiler zu schreiben. .NET hat mit dieser Diskussion nicht die Bohne zu tun. Langsam reicht es mir auch mit diesen elendig schlechten Argumenten. Oben steht: Beide Compilerphasen müssen optimieren. Warum? Da steht nirgends ein Argument, warum dem so sein sollte. Was suchen da Ergebnisse von .NET, wenn es hier um Java und die JVM geht. Und selbst wenn es um Ergebnisse der JVM gehen würde. Inlining und optimierte Garbage Collection bekommt man einfach so. Punkt aus. Und noch was zur Metrik. Die Idee an sich finde ich ganz offen gesagt, lächerlich. Wenn jetzt auch noch wer daher kommt und will von zwei, drei Compilerimplementierungen und der Schnelligkeit der Ausführung des generierten *Intermediate*-Codes auf irgendeine Metrik für diese Sprache(n) schließen... ich bin echt sprachlos.

Programm Fahrkartenautomat

Im Beispielprogramm werden viele Begriffe verwendet, die ein Anfänger, der noch nie Programmiert hat gar nicht kennen kann. Im Text wurden davon viele nicht erklärt. Hier eine Auswahl die mir beim überfliegen aufgefallen ist:

Variable, Datentyp, Funktion, Argument und Rückgabewert - nirgends sind die Begriffe erklärt. Folge: Jemand der noch nie eine Codezeile geschrieben hat (und dies ist die Zielgruppe des Buches) wird nur mit den Achseln zucken und weckklicken. Außerdem erinnert der Syntax sehr stark an C. Ich würde vorschlagen, dass sich das Programm ehr den Syntax von Basic orientieren sollten. -- Daniel B 20:54, 10. Dez 2004 (UTC)

Ich werde mir das nochmal anschauen, und überlegen, wie man das vermeiden kann (d.h. die Begriffe an geeigneter Stelle erklären). Was die Syntax angeht, kann ich deinen Einwand exakt garnicht verstehen. Ich meine, wenn einem die verwendete Syntax an Pascal erinnert, ist es ja ok, aber wie kommst Du gerade auf C? Abgesehen davon sehe ich keinen großen unterschied zwischen dem und Basic. Ich sehe einen viel größeren Unterschied zu C. --Bodo Thiesen 01:06, 12. Dez 2004 (UTC)

Ich schlage vor, die Syntax nicht an einer Programmiersprache zu orientieren, sondern an der natürlichen mittels Pseudocode. Im Endeffekt ist Syntax immer Geschmacksfrage. Ein guter Programmierer sieht über Syntax auch drüber hinweg oder hindurch, denn was zählt ist die Semantik. Und ich denke, die Bedeutung erschließt sich einem "Neuling" am besten, wenn er nicht gleich auch die Syntax noch neu lernen/hinterblicken muss. Etwas Prosa ist da sicherlich gut, denn das ist das was jeder kennt.

OOP veraltet?

Kapitel Programmierung des Bezahlprogramms:

Da gibt es zum Beispiel die objektorientierte Programmierung, die in den 1990er Jahren Furore gemacht hat und damals als modern galt.

Diese Aussage halte ich für irreführend. Man könnte meinen, dass die objektorientierte Programmierung veraltet ist und nicht mehr benutz wird. Dies ist allerdings falsch, wie neuere Sprachen wie Java oder C# zeigen, die die Objektorientierte Programmierung unterstützen. -- Daniel B 20:04, 21. Dez 2004 (UTC)

modern kann mann auch mit neu übersetzen aber OOP wurde tatsächlich von anderen paradigmen wie AOP etws abgelöst siehe C#, aber wie SP bleibt es bestandteil der sprachen.Lichtkind 17:43, 22. Dez 2004 (UTC)

OOP wurde nicht von AOP "abgelöst". Nach wie vor ist unklar wie und wo AOP einzuordnen ist. Die Toolunterstützung ist momentan spärlich und die Umsetzungen sind oft Flickwerk (mittels dynamischer Codeerzeugung und sowas). AOP ist dahingehend eher noch im experimentellen Stadium. Außerdem... "abgelöst" wovon? Was ist SP? Und noch was... bei Paradigmen von "modern" zu sprechen ist gefährlich. Da ist zuviel Interpretationsspielraum drin. "neu" ist sicher besser, oder, was wahrscheinlich die meisten meinen, wenn sie von modern sprechen: "in (Mode)".

SP heißt strukturierte Programmierung und gilt als veraltet. Dem kann ich nur zustimmen, so unstrukturiert wie die Programme heutzutage sind ;) --Herr Schroeder 11:13, 14. Jul 2005 (UTC)

Also dass OOP abgeloest wurde, glaube ich eher nicht.... Obj-C/Cocoa lebt von OOP und damit werden alle guten Mac OSX Programme geschrieben, also mit solchen Aeusserungen wuerde ich mich eher zurueckhalten. Hat jemand eine Idee, wie man das aendern koennte? Da es OOP schon seit den 80ern gab, kann man nicht sagen, dass es neu war. Am besten sollte man den Teil "und damals als modern galt." ganz streichen, oder? Neum 22:54, 23. Jul 2005 (UTC)

OOP gibt es seit Simula, welches in den 60ern entwickelt wurde.

C#

Warum wurde denn bei C# ein ganzer Absatz einfach entfernt? -- Daniel B 08:23, 16. Jan 2005 (UTC)

Das war zu viel des Guten. Nur einer von den beiden Sätzen sollte raus. Ich habe den Rest wieder eingefügt.

Paradigmen: Logikprogrammierung

Im Abschnitt Paradigmen steht "Logikprogrammierung". Was genau ist das?

Siehe in der Wikipedia Artikel Logikprogrammierung. Besser könnt ich es auch nicht erklären. Hoffe dir dennoch weitergeholfen zu haben. Gruß -- Daniel B 16:36, 29. Jan 2005 (UTC)

Englischkentnisse

Programmierer sind generell nicht sonderlich gut im Schreiben von Benutzerdokumentation

Das ist eine Unterstellung. Und was heißt Benutzerdokumentation? Für Enduser oder Programmierer, die meine Schnittstelle benutzen?

Tests

Der ganze Abschnitt über Qualitätssicherung macht wenig Mut ist wenig innovativ. Ich würde mir wünschen, dass der Unterschied zwischen automatisierten und manuellen Tests herausgestellt wird.

Einem Anfänger gleich zu Beginn zu erzählen, dass Tests eh nicht oft durchgeführt werden, ist schlecht. Dann sollte man auch gleich hinterherschieben, dass genau aus diesem Grund (nicht der alleinige) die meisten Projekte scheitern, wenn sie ein gewisse Größe erreichen.

Es sollte etwas auf agile Entwicklung und die Bedeutung von automatisierten Tests hingewiesen werden. Dass durch Tests weniger als 60% der Fehler gefunden werden, liegt an der mangelnden Disziplin mit der diese durchgeführt werden (im Schnitt). In einer agilen Entwicklung werden Tests kontinuierlich zugefügt, die einen gefunden Fehler abtesten. Der psychologische Vorteil von Tests und dass durch eine ordentliche Testsammlung das Ändern des Programms erst machbar werden würde ich mir da auch wünschen. Etwas motivationssteigerndes wie "Tests zu entwerfen unterscheidet sich nicht vom üblichen Softwareentwurf" oder von wegen gleiche Herausforderung wäre angebracht.

Für diese Änderungen müsste allerdings der ganze Abschnitt umgeworfen werden. Ich find in seiner jetzigen Fassung klingt das, als hätte es jemand geschrieben der sich mit Testen wenig beschäftigt, nicht auf dem aktuellen Stand ist bzw. wenig motiviert ist zu testen. Soll kein Angriff sein. Es klingt für mich eben so.

Ja, das Buch ist wirklich noch eine große Baustelle. Ich hab selbst bereits einiges im Abschnitt "Wählen einer Programmiersprache" überarbeitet. Währe nicht schlecht, wenn du bei dem Buch mithilfst. :-) -- Daniel B 20:07, 7. Feb 2005 (UTC)

Ideen

Wie wäre es mit einem Abschnitt über Kommentare von den Leuten hier, warum sie programmieren (gelernt haben)? Was sie toll am Softwareentwurf usw. finden?

Gliederung (Programmiersprachen)

Es scheint mir, daß eine Einrückungsebene fehlt: Sowohl prozedurale als auch objektorientierte sowie Scriptsprachen gehören zu den Hochsprachen (nicht aber die Auszeichnungssprachen, die schlicht keine Programmiersprachen sind und daher eh aus dem Rahmen fallen). Den Gegensatz zu den problemorientierten bzw. Hochsprachen bilden die Maschinen- und maschinennahen Sprachen.

Bei den Auszeichnungssprachen stimme ich zu. Die passen hier nicht rein. Wer glaubt, HTML sei eine Programmiersprache, kann ja mal versuchen, das Fahrkartenautomatenprogramm in HTML zu programmieren. --Pro 17:42, 13. Feb 2005 (UTC)

Ich denke, da sind wir aller einer Meinung. Allerdings dürft der Satz "Auszeichnungssprachen sind, streng genommen, keine Programmiersprachen,..." eigentlich ausreichend sein. (Wenn ich’s mir genau überlegen kann auch das "genaugenommen" aus dem Satz raus. Es sind keine Programmiersprachen und Punkt). -- Daniel B 17:51, 13. Feb 2005 (UTC)

Wann ist dann eine Sprache eine Programmiersprache? Stichwort XSLT. --Bastie 12:38, 27. Mär 2005 (UTC)

Einige Diskussionen hier (auch die um Hochsprache) zeigen mir, dass man nicht irgendwas einfach so definieren soll und fertig. Unterschiedliche Verwendung der Begriffe sollte herausgestellt werden, ebenso wie schwammige Grenzen. Programmiersprachen kann man nicht einfach von anderen künstlichen Sprachen abgrenzen. Postscript wird als Dokumentbeschreibungssprachen benutzt, ist an sich aber eine vollwertige Programmiersprache. Bei TeX sieht es ähnlich (vielleicht nicht ganz so) aus. HTML ist kritischer, es fehlen Elemente zur Steuerung des Kontrollflusses, Bedingungen usw. Ich will aber nicht sagen, dass das notwendige/hinreichende Kriterien sind. Ich hab mir noch nicht die nötigen Gedanken gemacht. Ich denke oft ist es einfach der Verwendungszweck, den eine künstliche Sprache zur Programmiersprache macht oder eben nicht.

Sinnvoll wäre m. E. noch eine Erläuterung des Unterschieds zwischen compilierten und interpretierten Sprachen. In diesem Zusammenhang könnte auch der Sonderfall Java kurz angesprochen werden (m. E. allerdings eindeutig eine compilierte Sprache, die eben normalerweise durch eine virtuelle Maschine ausgeführt wird, die ihrerseits ein Programm ist. --Tobias 21:48, 12. Feb 2005 (UTC)

Nein. Denn:

• Ob eine Sprache kompiliert oder interpretiert wird, ist ein Implementierungsdetail (mal abgesehen davon, dass es keine scharfe Abgrenzung zwischen Compiler und Interpreter gibt).

Hmm, ich denke das lässt sich scharf abgrenzen. Ein Compiler übersetzt eine Programm in einer Sprache in eins einer anderen. Ein Interpreter führt ein Programm in einer Sprache aus. Es gibt Programme, die sind Compiler und Interpreter, aber die Compilerteile lassen sich doch von den Interpreterteilen abgrenzen, oder? Anders als bei fließenden Übergängen, z.B. Tag und Nacht.

• Java ist in keiner Hinsicht ein Sonderfall: Ebenso wie Java können die anderen Sprachen interpretiert oder kompiliert werden. Ebenso wie Java können die anderen Sprachen auf einer VM ausgeführt werden (und sie werden es!!)
  --Pro 17:37, 13. Feb 2005 (UTC)

ACK -- Daniel B 17:51, 13. Feb 2005 (UTC)

Bitte trennen zwischen Programmiersprache Java, Java Plattform und Java Compiler (Stichwort native Compiler - der die ganze Diskussion wieder aushebelt). --Bastie 12:38, 27. Mär 2005 (UTC)

Englischkenntnisse

Der folgende Passus ist m. E. weit überzogen (Hervorhebungen von mir):

Sie sollten auch möglichst früh damit beginnen, Ihre Programme auf Englisch zu kommentieren und englische Variablen- und Bezeichnernamen zu wählen. Das Gleiche gilt für den Programmentwurf und die Programmdokumentation. Ehrlich gesagt, deutsche Variablen- und Bezeichnernamen und Kommentare sehen in professionellen Programmen ziemlich lächerlich aus. Alle Betriebssysteme und Bibliotheken verwenden englische Namen, die sich nicht ändern lassen. Mischt man das mit deutschen Texten, hat man ein ziemliches Kauderwelsch.

Wenn es um Open-Source-Projekte mit internationaler Beteiligung geht -- ok. Aber in der Realität ist es doch so, daß man sich einerseits unnötigerweise einen abbricht, um etwas korrekt in englisch auszudrücken, und sich anderseits mit dem Kauderwelsch seiner deutschen Kollegen herumschlagen muß, die das mehr oder eher weniger gut geschafft haben. Dann doch besser einen korrekten, präzisen, auf deutsch geschriebenen Kommentar. --Tobias 21:48, 12. Feb 2005 (UTC)

Hochsprachen

Da wurde ein Absatz weggenommen, mit der Begründung, dass C eine Hochsprache ist und der Absatz nicht mal so richtig das Gegenteil behauptet hat. Der Begriff Hochsprache ist deutlich umstritten. Viele behaupten C wäre eine, wahrscheinlich genauso viele meinen das Gegenteil. Andere sehen den Begriff relativ, so wie es da im Absatz stand. Ein Kommentar C ist ganz klar eine höhere Programmiersprache, sonst könnte der Quelltext wohl kaum auf verschiedenen Plattformen übersetzt werden ist arm. Das ist kein Kriterium für eine Hochsprache. Das ist das erste Mal, dass ich so einen bullshit gehört habe. Selbst Brian Kernighan geht in Interviews der Frage aus dem Weg, ob C eine Hochsprache ist oder nicht. Interview

Wenn C keine höhere Programmiersprache ist, was ist es dann? Ein Assembler? Wohl kaum, denn C hat maschinenunabhängige Datentypen, Datenstrukturen (Structs, Unions) und die Programme sind auf verschiedenen Rechner übersetzbar (was sehr wohl ein Kriterium für eine höhere Programmiersprache ist). Hast du irgendwelche Belege für deine Behauptung, C sei keine höhere Programmiersprache? -- Daniel B 12:20, 28. Mär 2005 (UTC)

... aber das ist doch genau der Punkt. Was auf mehreren Plattformen übersetzt werden kann, abstrahiert von einem Teil der Plattformen. Sowas wird also eine höhere Programmiersprache (als Assembler) sein. Aber was ist eine Hochsprache? Es gibt keine einheitliche Definition. Nun, vielleicht gibt es die, aber der Begriff wird von vielen unterschiedlich gebraucht. Genau das sollte der entfernte Absatz verdeutlichen. C ist an dem untersten Niveau, was ich mir unter einer höheren Programmiersprache vorstellen kann. Ein paar Schleifen, ein bischen Artihmetik, Funktionen und nichtmal wirkliche Modularisierung. Vielleicht hab ich was vergessen. Nochmal: "höhere Programmiersprache" nicht unbedingt gleich "Hochsprache". Niemand, der das Buch liest sollte den Eindruck bekommen, C sei in diesem Punkt zu vergleichen mit sehr viel höheren Sprachen (Eiffel, Haskell oder sogar Java).

Schaue doch mal bitte in der Wikipedia den Artikel Höhere Programmiersprache an. Dort sind einige Kriterien für höhere Programmiersprachen. Treffen da irgendwelche Merkmale für höhere Programmiersprachen auf C nicht zu? Und dann schau dir bitte noch im Artikel Programmiersprache den Absatz "3. Generation: höhere Programmiersprachen (high level language)" an. Dort ist als Beispiel C aufgeführt. Ich scheine also nicht der einzige zu sein, der C als höhere Programmiersprache ansieht.

Warum "Hochsprache" jetzt nicht gleich "höhere Programmiersprache" sein soll versteh ich auch nicht. Auch das kannst du in der Wikipedia nachschauen: Der Artikel Hochsprache ist eine Begriffserklärungsseite, der auf den Artikel höhere Programmiersprache verlinkt.

"Höher" stellt das Relative heraus, "Hoch" nicht (obwohl es auch relativ ist, es gibt kein absolutes "hoch").

Du schreibst: C ist an dem untersten Niveau, was ich mir unter einer höheren Programmiersprache vorstellen kann. Und? Macht das C jetzt zu etwas anderem als eine Hochsprache nur weil es deiner Meinung nach kein so hohen Abstraktionsgrad wie beispielsweise Java hat? -- Daniel B 20:02, 4. Apr 2005 (UTC)

Ich rede hier ja nicht nur über meine eigene Meinung. Ich denke nicht, dass irgendjemand qualifiziertes bestreitet, dass Java einen höheren Abstraktionsgrad als C hat, obwohl es noch viel weiter geht. Es ist ja auch nicht so, dass das mit der Begriffsdefinition und seiner Relativität mein eigener Einfall ist. Das wird heutzutage einfach relativ gesehen. Früher gab es quasi nur zwei Arten von Abstraktionen, Assembler und so Sachen wie Fortran. Da kann man leicht mit so Begriffen wie hoch und nicht-hoch um sich schmeißen. Wenn es aber weitaus abstrahierendere Sprachen gibt, macht eine ausschließliche Zweiteilung kein Sinn mehr. Das ist wie mit dem Volk aus dem Flachland. Der höchste Punkt in seiner Welt, den es kennt ist der selbsterschaffene Kirchturm (Fortran). Der wird als hoch bezeichnet. Kommt das Volk in ein Gebirge, macht dann der Begriff "hoch" für den Kirchturm noch Sinn? (Nicht zum Antworten sondern zum Nachdenken)

Zum Wikipedia-Artikel: Der ist nicht gut und teilweise falsch. Viel brauchbarer ist der Englische. Sind meine Argumente so schlecht, oder warum wird mir nicht geglaubt?

Okay, ich glaub ich verstehe jetzt was du meinst. Lass mir noch ein wenig Zeit um einen Kompromissvorschlag zu erarbeiten. Mir ist da gerade was eingefallen wie man das gut formulieren kann, hab allerdings jetzt grade keine Zeit das einzufügen. Ich hoffe ich komme heute Abend noch dazu. -- Daniel B 05:33, 5. Apr 2005 (UTC)

Was war an dem alten Text so schlecht bzw. was hat er nicht ausgedrückt, was rein sollte?

Also ich hab mir noch mal einige Bücher angesehen. Dort wird C immer als Hochsprache bezeichnet. Bei Assemblerbüchern ist auch immer von der Einbindung des Assemblers in Hochsprachen die Rede (davon kannst du dich beispielsweise hier überzeugen. Im Inhaltsverzeichnis der Assemblerbücher ist immer von „Einbindung des Assembler in Hochsprachen“ die Rede - auch im Zusammenhang mit C).

Ja, natürlich. Gegenüber Assembler ist C ja auch eine Hochsprache. Ich vermute auch mal, dass Du Dir Bücher über C und ähnlich hohe Sprachen angeschaut hast. Aber das ist nicht der Punkt. Mir war die Relativität des Begriffs wichtig. Niemand soll den Eindruck bekommen, C sei mit (viel) höheren Sprachen zu vergleichen. Sie als Hochsprache zu bezeichnen ist ja auch nicht grundlegend falsch. So stand das auch nicht in dem Artikel, nirgends ein Satz wie "C ist keine Hochsprache." Aber ich weiß auch nicht, ob sich lohnt hier so breit drüber zu diskutieren. Ich finde nur nicht in Ordnung, dass der Abschnitt einfach so gelöscht wurde. Die Begründung war nicht gut. Man kann einen Absatz ja umformen, wenn er nicht gut gelungen ist, aber sein Inhalt war korrekt.

Ich erlebe ständig Studenten, die meinen C sei eine hohe Sprache (im absoluten Vergleich) und schauen sich zu wenig fortschrittliche Konzepte an. Wenn man jemanden deutlich macht, dass C von seiner Ausdruckskraft heutzutage am unteren Niveau ist, und das möglichst früh, verfällt er nicht in so ein Denken. Er wird dann mit Sicherheit ein besserer Programmierer. Ein Begriff wie Hochsprache für alle Sprachen höher als Assembler ist da hinderlich.

Ich habe den Absatz jetzt wieder eingefügt, da ich nach unserer Diskussion der Meinung bin, dass er missverständlich geschrieben ist. Vielleicht sollte er dahingehend nochmals überarbeitet werden.

Und zu deiner Kritik an meinen Vorgehen: Ich gebe dir recht, dass ich hier etwas zu vorschnell war. Allerdings habe ich hier schon einigen Unsinn gelesen. (C-Sprachen, "beste Sprache", POV Beiträge). Es währe besser, du würdest dich anmelden, damit man deine Beiträge zuordnen kann. Das würde die Arbeit hier um einiges erleichtern. -- Daniel B 16:48, 9. Apr 2005 (UTC)

Ja, hier stand schon viel Schrott. Was genau würde es erleichtern, wenn ich mich anmelden würde?

Ich hätte erst mal auf deiner Diskussionsseite nachfragen können. Außerdem ist es leichter wenn man einen Beitrag einem Benutzer zuordnen kann, weil man dann einschätzen kann, ob was nur kurz hingekritzelt wurde oder die Beiträge wirklich fundierte sind. Ersteres ist bei anonymen Benutzern leider häufiger anzutreffen. Abgesehen davon macht es die Kontrolle leichter, weil man bei einem anonymen Benutzer wirklich jeden Beitrag nachprüfen muss u.a. auch wegen des oft vorkommenden Vandalismuses. Letztlich kann natürlich jeder unangemeldet hier mitarbeiten, aber eine Anmeldung beugt Missverständnissen vor. -- Daniel B 19:38, 10. Apr 2005 (UTC)

Im englischensprachigen Raum finde ich allerdings häufig die Bezeichnung Low-Level-Sprachen (beispielsweise bei C). Das scheint sich im deutschsprachigen Raum aber bisher nicht so durchgesetzt zu haben, wenn ich mir die Literatur ansehe. Ich wollte noch ein Abschnitt einfügen, dass hier zumindest im Englischen ein Unterschied zwischen High-Level und Low-Level-Sprachen besteht (hatte aber bisher noch keine Zeit). -- Daniel B 12:19, 9. Apr 2005 (UTC)

"Low-Level" ist kein Widerspruch zu "Hochsprache". "Low-Level" = maschinennah. C ist eine maschinennahe Hochsprache. Nicht fragen "Wo auf der Skala befindet sich die Sprache?", sondern "Welches Spektrum deckt sie ab?". Das ist eine differenziertere Betrachtungsweise. --Tomas 17:01, 9. Apr 2005 (UTC)

Mich würde ein Beispiel interessieren. Welche Sprache ist maschinennah und von hohem Abstraktionsgrad (gemessen an Eiffel/Haskell z.B.)? Was meinst Du mit der letzten Frage genau?

"hoher Abstraktionsgrad" entspricht nicht ganz der Aussage, denn die Bedeutung von "Hochsprache" ist vielleicht nicht ganz eindeutig. "Hochsprache", würde ich deshalb sagen, ist nicht gleichzusetzen mit hohem Abstraktionsgrad.

Nun, da haben wir dann eine unterschiedliche Auffassung.

Der Unterschied zwischen unseren Auffassungen besteht darin, dass ich davon ausgehe, dass das Wort "Hochsprache" mehrere Bedeutungen haben kann, du dem Wort aber nur eine Bedeutung zugestehst.

Dann teile uns bitte mit, was Du noch unter dem Begriff verstehst. Ich kann Dich sonst nicht verstehen.

Eine Hochsprache kann auch relativ gering abstrahiert sein, sie liegt nur eben, quasi als Mindestforderung, in ihrer Abstraktion über dem Niveau einer Maschinensprache.

Das wirft alles bis hierhin gesagte (über Relativität des Begriffs usw) über den Haufen.

Sehe ich an dieser Stelle nicht. Könntest du das näher erläutern?

Der Begriff an sich ist relativ. Zumindest dort, wo ich mich bisher herumgetrieben habe. C hoch gegenüber Assembler, die meisten moderneren Sprachen höher als C. Es macht wenig Sinn alles über Assembler als hoch zu bezeichnen. Erst recht in einem Einsteigerbuch. Das habe ich schon etliche Male versucht dort oben mitzuteilen.

Zu Eiffel oder Haskell kann ich leider nichts sagen (bin aber neugierig auf das, was du ggf. darüber weißt). Aber nehmen wir beispielsweise den integer-Typ im Vergleich zwischen C und Java. In Java hat der Typ immer eine feste Größe, in C dagegen wird er möglichst nah an die Architektur der Zielmaschine angepasst.

Versteh ich nicht. Was heißt "hat immer eine feste Größe"?

Man kann auch sagen "feste Länge".

Gleichzeitig gibt es in C die Möglichkeit, sich auf einen integer-Typ fester Länge zu beziehen, also wie in Java. Das ist das Prinzip: gleicher Abstraktionsgrad (feste Länge bei beiden Sprachen) aber auch (und bei C in erster Linie) eine maschinennahe Variante. Deshalb sind Abstraktion und Maschinennähe kein Widerspruch.

Ja, ein Widerspruch in sich gibt es da generell nicht unbedingt. Der Sprung den C da macht ist nur nicht gerade groß. Ich seh kaum eine Abstraktion. Als ich das letzte Mal C programmiert habe (schon etwas her) abstrahierte es nicht mal von LSB/MSB first (x86<->PowerPC z.B.).

Meinst du "Big Endian"/"Little Endian"?

Ja. Mein Ausdruck war nicht korrekt.

Einen Integer fester Länge nehmen zu können, kann man nicht grad als Abstraktion bezeichnen.

Doch, es ist auch eine Art Abstraktion. Es abstrahiert die tatsächliche Länge.

Low-level und hohe Abstraktion beißen sich aber, deswegen habe ich nach einem Beispiel gefragt (ich schließe nicht *ganz* aus, das es sowas gibt oder geben kann).

Low-Level im Sinne von maschinennah mag ein Gegensatz zu hoher Abstraktion an sich sein. Eine Programmiersprache kann aber beide Welten durch unterschiedliche Sprachbestandteile abdecken. Ich habe ja ein Beispiel genannt. Siehe auch die Grafik (unten).

Je maschinennäher die Sprache desto weniger Abstraktionen besitzt sie allein aus praktischen Gründen. Das eine zieht das andere nach sich.

Im Gegenteil, maschinennahe und abstrakte Sprachelemente können einander gut ergänzen.

Die Welt der Bits und Register ist eine ganz andere als die von abstrakten Typen beispielsweise. Innerhalb dieser Typen kann ich zwar mit Bits rumspielen, nach außen darf das aber nicht sichbar sein. Jemand der eine recht abstrakte Sprache benutzen will, will sich nicht um diese Dinge kümmern. Das sind verschiedene Schichten. Außerdem kann man Abstraktionsgrade auch nicht immer miteinander vergleichen. (Reine) Funktionale Sprachen abstrahieren (stark) von der von Neumann Architektur. Logische auch. Beide besitzen eine andere Art von Abstraktion.

Was sagst du nun zu der Skizze? Und was kann man zu Eiffel und Haskel sagen?

Die Skala ist irreführend. Der Balken von C gehört viel kürzer. Eiffel und Haskell setzen am Ende (aber noch im Balken) ein und gehen sehr viel weiter. Aber man kann die beiden nicht auf so einer Skala vergleichen, eben wegen der unterschiedlichen Paradigmen (OO/imperativ <-> funktional). Außerdem scheinen wir sehr unterschiedliche Sachen im Kopf zu haben, wenn wir von Abtraktionen reden. C bietet aus heutiger Sicht kaum Abstraktionen. Sie beschränken sich auf das was manchmal "Programmieren im Kleinen" genannt wird. Kein Modulkonzept, keine Polymorphie usw. Aber ich bin ehrlich gesagt wieder aus dem Tritt gekommen, worüber wir geenau diskutieren. Ich muss mir das mal in Ruhe durchlesen.

Erst einmal Danke für die Antworten. Ich muss sagen, der Balken von C gehört tatsächlich kürzer. Was die Abstraktion betrifft, meine ich, dass der Begriff an sich sehr vielfältig und vielleicht auch schwer zu fassen ist. Kein Wunder, dass wir unterschiedliche Vorstellungen davon haben. Zur Definition von "Hochsprache" habe ich zwei Zitate.
1. aus der englischen Wikipedia unter "high-level programming language": A high-level programming language is a programming language that is more user-friendly, to some extent platform-independent, and abstract from low-level computer processor operations such as memory accesses.
2. vom Wiki c2.com unter "HighLevelLanguage": The term "High Level Language" was originally used to distinguish things like Fortran from things like assembly language. Therefore, originally "high level language" very much included Fortran, Basic, COBOL, Snobol, PL/I, and a little later, C.
Observing that such languages are not very high level compared with e.g. Prolog, YACC, Lex, ML, Haskell, etc, some people started calling the older high level languages "low level languages", or qualifying them as "higher level languages", etc. This is largely revisionism by SmugLanguageWeenies?, and such terminology is certainly not universally accepted, even though there is no doubt but that some languages are more sophisticated than others.
A more neutral approach to the topic would be to simply call more sophisticated languages "very high level languages", if a distinction is needed, rather than trying to snidely imply (or state outright) that there's no difference between assembler and Fortran, Basic, COBOL, Snobol, PL/I, C etc. --Tomas 17:49, 13. Apr 2005 (UTC)

Das sollten alle an der Diskussion beteiligten gelesen haben. Es untermauert ja auch mein Anliegen. Du hast noch nicht geschrieben, was Du unter Hochsprache verstehst. (Die beiden Artikel beziehen Stellung: The word "high" [does not imply...] rather refers to the higher level of abstraction from machine language und A HighLevelLanguage is a ProgrammingLanguage that supports system development at a high LevelOfAbstraction.)

Was ich mit der letzten Frage meine, sei an einer Skizze verdeutlicht:

                                   "Spektren":
           niedrige Abstraktion                       hohe Abstraktion
           -----------------------------------------------------------
C                 ###############################
Java                           #######################
Sprache X                           #########
Sprache Y      #########

             zum Vergleich die andere ("punktuelle") Sichtweise:
           niedrige Abstraktion                       hohe Abstraktion
           -----------------------------------------------------------
C                                |
Java                                       |
Sprache X                               |
Sprache Y          |

--Tomas 17:28, 11. Apr 2005 (UTC)

Plattformunabhängigkeit

Wenn es um die Plattformunabhängigkeit geht, würde ich zunächst einmal folgende Einteilung treffen:

1. Plattformunabhängigkeit auf Quelltextebene

2. Binäre Plattformunabhängigkeit

Dabei interessiert uns Punkt 1 bei der Betrachtung der Sprache an sich. Hier "punktet" Java durch eine starke Vereinheitlichung für alle verfügbaren Plattformen (abzügliche Bugs), ebenso C#. C dagegen verhält sich je nach Plattform anders, und zum Teil sogar innerhalb einer Plattform je nach Compiler. Stimmen wir bis hierhin überein? :-) Pro 19:54, 14. Feb 2005 (UTC)

Ist das Mono Projekt so kompatibel? --Bastie 12:28, 27. Mär 2005 (UTC)

etwas Kritik

Java

Für den Programmieranfänger, der Java als Erstsprache wählt, ist das Erlernen der Sprache deshalb mit einem sehr hohen Lernaufwand verbunden. Kann ich nicht bestätigen. Problematisch war es genau für die Leute die vorher eine prozedurale Sprache gelernt hatten. Wer unbedarft kam, hatte kaum Probleme. Problematisch ist eher OO zu entwickeln / programmieren. --Bastie 12:28, 27. Mär 2005 (UTC)

Na ja, für den - ich will ihn mal "Hobbyprogrammierer" nennen - ist Java zu lernen schon ein recht hoher Aufwand. Für den, der für Studium und/ oder Beruf programmieren lernt, spielt das natürlich weniger eine Rolle. Hobbyprogrammierer sollten sich vielleicht erst mal mit Visual Basic oder was Ähnlichem beschäftigen, wo sie dann auch schnell ein Ergebnis erreichen können. Daher das mit dem hohen Lernaufwand. Aber vielleicht kann man das ganze noch besser formulieren. -- Daniel B 12:10, 28. Mär 2005 (UTC)

rho: Ich empfehle den Hobbyprogrammieren Gambas. Man kann genauso einfach anfangen wie mit Visual Basic und kann damit schon zwar einfache, aber recht brauchbare Anwendungen entwickeln. Steigt man dann in die Materie tiefer ein, bietet Gambas auch ganz ausgereiftes OOP.

Siehe Gambas,

Okay, Visual Basic oder Gambas. -- Daniel B 18:01, 28. Mär 2005 (UTC)

Ich würde keine Programmiersprache empfehlen. VB hat gewisse Konzepte, welche einem das erlernen anderer Programmiersprachen erschwert ähnlich ist es bei Java oder Cobol ... --Bastie 15:32, 5. Apr 2005 (UTC)

Ich könnte mir verschiedene Sprachen für Anfänger/Hobbyprogrammierer vorstellen, nur von Basic würde ich dringend abraten. Basic war ürsprünglich als Anfängersprache gedacht und hat seither in diesem Anspruch, trotz aller Evolution, auf ganzer Linie versagt. Mein Tip: Finger weg von Basic! --Tomas 16:51, 9. Apr 2005 (UTC)

XML

XML ist IMHO keine Auszeichnungssprache sondern eine Metasprache, die zur Definition eigener Sprachen genutzt wird. Daher gibt es auch XSLT und DTD.

ACK, kann aber gerade nicht die Textstelle finden, in der das behauptet wird. -- Daniel B 12:10, 28. Mär 2005 (UTC)

XML = eXtensible Markup Language = erweiterbare Auszeichnungssprache. Folglich ist es eine Auszeichnungssprache. --Tomas 16:51, 9. Apr 2005 (UTC)

Beispielprogramm Fahrkartenautomat

Ich möchte kritisieren, dass das Beispiel "Fahrkartenautomat.zip" ausschließlich in einer Version für Excel zur verfügung steht. Hier sollte man zumindest alternativ eine Version für OpenOffice zur Verfügung stellen, mit einem Link zum OpenOffice-Download.

Wenn's dir nicht gefällt, steht's dir frei das zu ändern. -- Daniel B 18:26, 29. Mär 2005 (UTC)

Ich möchte anmerken, dass das Programm bei mir abstürzt, als es einen restbetrag von 0,499999999999 Euro berechnet hat und ich diesen auszahlen wollte *lol*

Allgemeines zu den Programmiersprachen

Ich will ja hier niemadem auf den Fuss treten, aber die Texte über Programmiersprachen sind ähm... suboptimal.

1. C: Es ist ja allerehrenwert, Anfänger erst einmal von C fernzuhalten, aber die latente Behauptung, C wäre nur für maschinennahe Programmierung wirklich geeignet widerlegen alle GNOME Programme zusammen. Es gibt auch GUI programmierun jenseits der Windows API.
2. Basic würde ich auch heute noch nicht für Anfänger empfehlen. Es hat immer noch zu viele Altlasten, die den Anfänger unter den Programmierern zu Schlampigkeiten verleitet, die er dann, wenn er später einmal C++ Programme schreibt besser lassen sollte. Da halte ich Pascal basierte Sprachen, Python, oder Java eher als empfehlenswert, weil in unterschiedlichen Massen die nötige Disziplin erzwungen wird.
3. C++: Auch nicht gerade eine Einsteigesprache, aber C++ ist nicht nur eine Objektorientierte Sprache, sondern eine Multi-Paradigmen Sprache, was zum großen Teil die Komplexität ausmacht. C++ unterstützt nicht nur die objektorientierte und als Altlast die prozedurale Programmierung, sondern auch die funktionale Programmierung mit Funktoren (Klassen, die den '()'-Operator überladen) und die generische Programmierung mit Templates. Der Template Mechanismus als Turing-vollständiges Makro System wird gar nicht erwähnt.
4. Java ist ja für Einsteiger OK, aber mir ist der Weg von C++ zu Java eher schwer gefallen, weil vieles nicht mehr so einfach mit ein paar Templates und Mehrfachvererbung zu machen ist. Der Wechsel in die andere Richtung ist nach meiner Einschätzung eher einfacher, wenn auch nicht geschenkt.
5. Funktionale Programmierung und andere fortgeschrittene Paradigmen fehlen vollständig. Wenigstens eine kurze Erwähnung, dass es da noch was gibt wäre angebracht.
6. TeX und Postscript sind Turing-vollständige Sprachen und scheinen so gesehen neben HTML etwas fehl am Platz.

Mir ist in diesem Buch HTML noch nicht aufgefallen, aber HTML ist hier überhaupt fehl am Platz. Hier geht es primär ums Programmieren und nicht um Formale sprachen. HTML mag zwar eine Textauszeichnungssprache sein, aber es ist keine Programmiersprache.

Zustimmung 84.155.139.114 16:23, 17. Aug 2005 (UTC)

Im Zuge von JavaScript wird man sich wohl wieder mit HTML befassen müssen, da aber JavaScript eine rein im Zusammenhang mit HTML interressante Sprache ist, gehört das auch schon fast nicht mehr in die Kategorie Programmieren sondern mehr nach Web Design.

JavaScript bzw. ECMAScript und diverse Dialekte werden nicht nur mit HTML eingesetzt: XUL/XBL ohne JS ist relativ nutzlos; Es gibt Server-side JS; QT Script ist ein ECMAScript-Dialekt; Der Windows Scripting Host kennt auch einen JS interpreter; IIRC kann man JS auch unter OSX zur Automatisierung verwenden; OOo2 kann unter anderem auch JS; etc. 84.155.139.114 16:23, 17. Aug 2005 (UTC)

Ich wäre also dafür, HTML und ggf auch JavaScript raus zu schmeißen.

HTML ja, JS ist schon auch wichtig - wenn die oben genannten EInsatzmöglichkeiten angerissen werden können - es könnte ber evtl. auch einen Anfänger überfordern. 84.155.139.114 16:23, 17. Aug 2005 (UTC)

Was TeX & CO angeht. Da man damit idR nicht Programmieren wird (ja ich weiß, da gibt's nen BASIC Interpreter), sondern diese "nur" für die Beschreibung von (meist zu druckendem) Text verwendet wird, neige ich dazu, auch diese auszuwerfen. Alternativ könnte man darauf hinweisen, daß es diese gibt, es dann aber auch dabei zu lassen und nicht näher darauf einzugehen. --Bodo Thiesen 15:41, 16. Jul 2005 (UTC)

Oder kurz erwähnen, dass es da auch noch Programmiersprachen gibt, die normalerweise nicht als solche verwendet werden und dann PS und TeX als Beispiele anführen. 84.155.139.114 16:23, 17. Aug 2005 (UTC)

1. XML als Auszeichnungssprache zu bezeichnen ist auch kritisch. Viele XML Anwendungen setzen die XML Syntax für Auszeichnungssprachen ein, aber z.B. XSL/T ist eher eine Programmiersprache mit eingeschränktem Aufgabenbereich (Transformation von Baumstrukturen).
2. Ich kann nicht bestätigen, dass JScript "einen größeren Funktionsumfang" bietet als JavaScript. So fehlt z.B. die Möglichkeit, für eingebaute Prototypen (z.B. HTMLnode) neue Methoden zu definieren, oder vorhandene zu überschreiben. Das geht bei JScript nur für die aus den Prototypen resultierenden Objekte. Alles in Allem gefällt mir persönlich JavaScript besser als JScript, aber einen Unterschied in den Möglichkeiten der Sprachen (nicht der Platformen) kann ich nicht feststellen. Der Objektbasierte Ansatz mir Prototypen wird als Spezialität nicht einmal erwähnt. Bei JavaScript und JScript zeigt sich auch der Mangel, dass die funktionale Programmierung, keine Erwähnung findet.
3. PHP fehlt völlig - ich habe einen Absatz eingefügt, der aber noch nicht wirklich der Weisheit letzter Schluss ist.

Dieser Kritik stimme ich in Teilen zu. Allerdings trifft sie IMO nicht den Kern des Problems. Diesem Buch fehlt ganz klar eine Zielsetzung. Bisher ist es eine Ansammlung von nur beschränkt brauchbaren Informationen, von denen man mehr als die Hälfte getrost wegschmeißen kann. Für einen Anfänger bringt das alles nix. Anstatt Grabenkriege zu führen, würde ein objektive und vor allem moderne Sicht der Dinge gut tun, die nicht sinnlose Dinge wie Laufzeiteffizienzvergleiche von brauchbar effizienten System anführt. Man sollte einen Anfänger auch nicht mit haarfeinen Vergleichen von Sprachen langweilen. LaTeX ist turing-mächtig, aber welcher Leser der Zielgruppe kann damit was anfangen? LaTeX wird als Dokumentenbeschreibungssprache benutzt, also eine Sprache mit denen man ein Dokument "layouten" kann. Sowas interessiert. Das große, komplexe C++ braucht man gar nicht am Anfang erwähnen. Templates? Funktoren? Überladen? Mächtige Sachen in einer miesen Sprache (ich warte auf Haue :)) von einem Sprachdesigner, der sie offen gesagt nicht mehr alle hat (auweia).

Du hast tatsächlich den grundsätzlichen Punkt für meine Kritik prägnanter formulert als ich: "Anstatt Grabenkriege zu führen, würde ein objektive und vor allem moderne Sicht der Dinge gut tun." Ich finde auch, dass es eigentlich nicht nötig ist, in einem solchen Buch so ausführlich zu begründen, warum man Java als Programmiersprache für Einsteiger verwenden will. Wenn man das aber tut, dann ist es unangemessen zu versuchen, Java durch schlechtmachen der anderen Sprachen hervorzuheben. Damit wird man keiner der Sprachen gerecht - auch Java nicht.

Ein Übersicht über andere Sprachen mit kurzen Anmerkungen über deren Besonderheiten ist auch etwas anderes als der von mir Kritisierte Abschnitt.

Zu C++: Wir sind uns vollkommen einig, dass diese Sprache für Einsteiger völlig ungeeignet ist. Insofern würde es genügen in einem solchen Buch zu sagen, dass es C++ gibt, dass diese Sprache sehr mächtig ist und dass sie deshalb auch sehr komplex ist. Man muss da nicht irgendeinen Unsinn schwafeln, um Java dagegen hervorzuheben. Das ist in einem solchen Buch unnötig.

Persönlich bin ich der Ansicht, dass C++ eine sehr gute, wenn auch schwer beherschbare Sprache ist. Sie ist nicht für alles, aber für vieles besser geeignet als andere Sprachen und wenn es dich interessiert, kannst du von Stroustup auch für jedes einzelne Sprachkonstrukt eine gute Begründung haben. Trotzdem muss für mich nicht alles in C++ geschrieben sein, schon gar kein Anfängerbuch. Ich keine keine universell "beste" Programmiersprache. Ich weiss aber, dass für bestimte Anwendungen einige besser geeignet sind als andere.

Vorhergehende Diskutanten haben keine Überschriften angegeben. Bitte in Zukunft pro Absatz unterschreiben. --Bodo Thiesen 15:41, 16. Jul 2005 (UTC)

Was die Verwendung von Fachbegriffen wie Funktoren & CO bei Beschreibungen von Programmiersprachen angeht: Ich denke, das Kapitel "Fahrkartenautomat" gehört - sobald es brauchbar ist - wieder nach vorne. Dort passiert das für den Leser interressanteste. Dort sollte man dann anhand komplexerer Beispiele diese Fachbegriffe einführen. Ist das getan sollte man die Programmiersprachen und die von ihnen verwendeten Konzepte vorstellen (dann dürfen diese Begriffe auch als bekannt angesehen werden). Diese beiden Kapitel sollten IMHO die letzten beiden Kapitel des Buches sein, da sich der Leser danach hoffentlich für die für ihn am besten geeignete Programmiersprache entscheidet, und zum entsprechenden Buch weitergeht. Der ganze Rest des Buches sollte daraufhin untersucht werden, ob er sich sinnvollerweise in eines der beiden Kapitel eingliedern lässt oder davor erwähnt werden kann/soll. Trifft beides nicht zu: Ersatzlos löschen. --Bodo Thiesen 15:41, 16. Jul 2005 (UTC)

Worauf kommt es an? Leichte Erlernbarkeit und Verständlichkeit der Sprache. Zugleich darf sie den Programmierer nicht "verderben", so wie das C oder C++ machen (nochmal Haue). Zeigergefummel, Speichermanagement, obskure Semantik (C++) und komplexe Grammatik braucht ein Anfänger einfach nicht. Wer das machen will, der darf sich austoben, auch gerne im GNOME Projekt. Effizient ist man aber auch da nicht. Es gibt dort eine breite Coderbasis, deswegen ist da überhaupt was großes draus geworden. Das veraltete und lächerliche Argument der Laufzeiteffizienz einer Sprache/eines Systems hat hier nix zu suchen. Warum auch? Ein Anfänger will programmieren lernen und weiß noch gar nicht, was er später genaues machen will/soll. Vielleicht merkt er auch, dass programmieren nix für ihn ist. Soll man dann seine Zeit damit verschwenden und ihm nutzloses Zeugs (oder mindestens Zeugs das nicht im Verhältnis zwischen Aufwand und Nutzen steht (Zeiger!, Speichermanagement!)) beibringen? Oder vielleicht muss er niemals in seinem Leben ein auf Biegen und Brechen effizientes Programm schreiben. Programmieren lernt man nicht durch Programmieren von effizienten Programmen sondern durch effizientes Programmieren.

Meiner durchaus begründeten Meinung nach verdirbt Basic mit seinen schwächen den Programmierstil mehr als C und C++. C und C++ erzwingen eine disziplinierte Arbeit und einen überlegten Umgang mit Resourcen. Das ist für Anfänger eine Überforderung und deshalb halte ich Java, Python und Pascal auch für gute Einsteigersprachen. Dort wird bereits in ausreichendem Maß Disziplin eingeübt ohne den Lernenden von Anfang an zu überfordern.

Java kennt zwar keine Zeigerarithmetik, aber Zeiger schon. Wenn man mit Java arbeiten will kann man auch gleich mit C++ arbeiten, das eine delete pro new zusätzlich macht den Kohl nicht fett. So lernt man wenigstens von Anfang an, daß man daran denken muß, belegte Ressourcen auch wieder freizugeben. Letztlich muß man das auch in Java, nachdem Java keine Destruktoren kennt.

Das mit den Zeigern ist Begriffsreiterei. Überlicherweise ist der Unterschied zwischen Zeigern und Referenzen, der dass man sich bei Zeigern bewusst ist, dass man da ein Stück Speicher in der Hand hält. Bei Referenzen nicht. Deswegen wäre ich vorsichtig mit der Behauptung Java hätte Zeiger. Nach dem üblichen Verständnis hat es keine.

Dein Kommentar über Java und C++ klingt so, als wäre der einzige Unterschied zwischen C++ und Java der Garbage Collector, der nach Deiner Aussage keinen hohen Stellenwert hat. Speichermanagement erfordert viel Arbeit, sehr viel Arbeit. Es kommt nicht (nur) auf die korrekte Anzahl der "deletes" an, sondern auf den korrekten Ort und die korrekte Zeit. Das kann bei relativ simplen GUI-Sachen z.B. schon sehr komplex werden. Andererseits ist das nur einer der vielen Vorteile die Java gerade für Anfänger mitbringt. Aber das sollte man überall nachlesen können. Ich wollte nur drauf aufmerksam machen.

Python kenne ich nur vom Namen (hab auch schon mal zwei drei Quellen angesehen, würde aber nicht behaupen Python zu können) halte mich da also raus.

Da lohnt sich ein genauerer Blick. Die Sprache schafft es, den Anfänger zu Disziplin anzuleiten ohne einen Erfahrenen Progammierer zu stark zu behindern.

Pascal: Das war meine zweite (mit Assembler dritte) Programmiersprache. Weches von Basic, weil QBASIC zu beschränkt war, und keine exe Dateien erzeugt - nur interpreter. Naja auf jeden Fall ist Pascal eine feine Sprache, hat aber den Nachteil, daß ein Anfänger da wieder mit vielen Sachen konfrontiert wird, die er nicht unbedingt versteht.

... Die er aber verstehen muss, wenn er später ernsthaft Programmieren will. Genau an dem Punkt würde Basic ihm mehr im Weg stehen als nützen. Bei mir war der Weg übrigens: C=64-Basic - Pascal - 6502 Assembler - 6800 Assembler - C - C++ - Java und diverse Skriptsprachen (Perl, PHP, später auch Python, etc.). Der schwierigste und notwendigste Schritt war definitiv von Basic weg.

Ich halte Basic nach wie vor für eine geeignete Programmiersprache für Einsteiger, weil man dort schnelle Erfolgserlebnisse bekommt.

Das ist nur sehr begrenzt ein Argument. Es ist richtig, dass man mit Basic weniger Zeilen schreiben muss um ein "Hello World!!" auf dem Bildschirm zu haben, aber in den meisten Büchern kenne ich das so: Hello-World-Pogramm ist abgedruckt und Leser wird aufgefordert, es einzugeben; danach wird das Programm schrittweise zerlegt und erklärt, wobei der Leser gleich lernen kann, was z.B. Prozeduren, Variablen, etc. sind (zumindest hat er dann eine grobe Vorstellung davon). Er hat also zwar einige Minuten mehr in das Hello-World-Programm investiert, aber auch gleich viel mehr gelernt.

Jeder Programmierer wird schnell merken, daß GOTO nicht der Weisheit letzter Schluß ist, und mit brauchbaren Basic Dialekten kann ich auch dort prozedural programmieren.

Ein Programmierer weiss das, aber der liest auch kein Anfängerbuch. Wenn du ein Anfängerbuch schreibst, dann geh davon aus, dass dein Leser nichts weiss, was du ihm nicht sagst.

Man kann sich aber wie gesagt anfangs auf die Algorithmen beschränken. --Bodo Thiesen 15:41, 16. Jul 2005 (UTC)

Genau die interessieren aber doch einen Leser erst viel später. Zuerst will er wissen "wie schreibt man irgendein Programm?" und erst später "wie schreibe ich ein Programm, das zwei Listen sortiert?" o.Ä.

Das Thema Effizienz ist auch ein zweischneidiges Schwert. Bin ich effizient, wenn ich schnell ein Programm fertig habe? Dann sind Skriptsprachen zu empfehlen. Bin ich effizient, wenn mein Programm möglichst wenig Rechenleistung oder Speicher (ja was denn nun im Zweifel) verbraucht? Dann geht immer noch nichts über optimierte Algorithmen in handoptimiertem Assembler. Meistens liegt das Optimum irgendwo dazwischen und je nach dem, wo es für das jeweilige Projekt liegt, sollte man auch die Sprache wählen - ob dann C, C++, Java, Python, oder sonst was herauskommt.

Da sind wir einer Meinung. Effizient sein bedeutet für Anfänger allerdings etwas ganz anderes als für Entwickler an Code, der für Anwender bestimmt ist. Ich drücke mich etwas umständlich hier aus. Erst wollte ich schreiben, ... als für Entwickler mit einem Produkt als Ziel oder so ähnlich, aber da bin ich darauf gestoßen, dass der eigentliche Unterschied genau darin liegt. Sie haben ein anderes Ziel. Anfänger wollen programmieren lernen. Das ist aber kein Ziel anderer Qualität denke ich. Deswegen bedeutet für Anfänger "effizient programmieren", viel dabei und vor allem das Wesentliche zu lernen ohne unnötigen Balast mit herumzuschleppen. Ich denke, das hatte ich auch in Gedanken als ich den ursprünglichen Absatz oben formuliert habe. In Sprachen wie C++ (und auch Java, da aber erst später) gelangt man schnell an einen Punkt, an dem man nicht mehr effizient ist, weil man sich um zuviel Kleinkram kümmern muss (das ist auch wieder abhängig voin der Sichtweise, ganz klar). Aber hier muss man sich auch entscheiden, was das genaue Ziel ist. Sollen mehrere Paradigmen frühzeitig beigebracht werden? Beschränkt man sich auf eins? Geht man generell imperativ an die Sache? Will man früh auf mögliche Abstraktionen verweisen? Mehrere Sprachen gleichzeitig oder nur am Rande oder gar nicht? Und wer ist der Leser überhaupt? Ein Student mit 12/13-jähriger Schulerfahrung oder ein mathematisch völlig unbedarfter mittvierziger oder..., da gibt es noch viel mehr was alles geklärt werden sollte damit das hier einen einheitlichen Schliff bekommt.

Lasse die Leute BASIC lernen. Dort führt man ein paar Algorithmen ein, sortiert ein Datenfeld usw. - Grundlagen halt.

Das kannst du z.B. mit Python auch haben ohne die unzähligen Probleme, die man mit Basic hat (jede Implementation hat auch ihren eigenen Dialekt; jede Implementation bringt ihre eigenen Libraries mit; Basic verdirbt den Programmierstil; etc.)

Sobald es ans eingemachte geht, und die Chance besteht, es komme was Produktives dabei raus, wechselt man die Sprache, meinetwegen C oder Pascal bzw. führt in Basic FUNCTIONs und SUBs ein.

Pascal ist explizit als Lernsprache gedacht und stößt tatsächlich bei größeren Projekten eher an seine Grenzen als z.B. C. Pascal ist eine gute Sprache für den Einstieg, weil Grundkonzepte ubnd Disziplin vermittelt werden. Man kann auch relativ schnell zu Erfolgserlebnissen kommen ohne sich (wie mit Basic) an schlechte Programmstruktur und schlecht geplantes Vorgehen zu gewöhnen.

Will man nachher was echt großes, geht man zu C++ oder (*würg*) Java über.

So schlecht ist Java gar nicht. Ich arbeite zwar bei größeren Projekten lieber mit C++, aber es gibt schlimmeres als Java - z.B. Basic.

Skriptsprachen würde ich erst später erwähnen, weil man wenn man schon C oder C++ von der Geschwindigkeit her kennt und gewöhnt ist, wenigstens den Unterschied zu Skriptsprachen mitbekommt. Dann merkt man, welcher unterschied es ist, ob ich mit Python oder mit C++ eine Baumstruktur auswerte. Dann merkt man wenigstens, womit man leichte Anderbarkeit und schnelles Programmieren erkauft. --Bodo Thiesen 15:41, 16. Jul 2005 (UTC)

Man sollte an Perl tatsächlich nur Leute lassen, die vorher schon einmal Disziplin gelernt haben, aber das lässt sich nicht auf alle Skriptsprachen verallgemeinern - Python ist ein schönes Gegenbeispiel.

Man darf einem Anfänger auch Dinge beibringen, die nicht 100%ig stimmen, solange der Lernaufwand nicht zu hoch ist, das fehlende Stück dazuzulernen. Ich denke da an Speichermanagement, mit welchem man sich auskennen muss, wenn man große (nicht das groß was hier anscheinend viele im Kopf haben, sondern größer (aua)) halbwegs effiziente Systeme entwerfen möchte, das aber am Anfang völlig unnötiges Wissen ist (eigentlich stimmt das Gegenteil: es hindert eher, weil es einen Ballast darstellt).

Da haben wir einen grundsätzlichen Gegensatz. Ich treffe oft genaug auf etwas Fortgeschrittene, die aber noch die "nicht 100%igen", Dinge aus ihrem Anfängerbuch im Kopf haben. Wenn man es nicht 100%ig so erklären kann, dass der Anfäger es versteht, kann man 1. es einfach per Definition festschreiben (wenn das Wissen später nötig ist), 2. es weglassen, oder 3. auf eine ausführlichere Quelle verweisen. Wenn aber die Leute dann mit Halb- und Unwahrheiten im Kopf herumlaufen und Entscheidungen treffen, bzw. Angebote einschätzen wollen, dann schadet es ihnen oft mehr als es ihnen hilft.

Man muss dabei sehr wohl darauf verweisen, dass man an jener Stelle etwas vereinfacht oder sowas. Und später das Thema soweit wieder aufgreifen, dass zumindest keine Halb- und Unwahrheiten bleiben. Ich bin bei sowas immer für inkrementelles Vorgehen, nur soviel wie zur Zeit nötig, aber natürlich die Geschichte zu Ende bringen. Dabei müssen die "Inkremente" immer in Bezug zu den vorherigen gebracht werden, damit das funktioniert.

Ich hab jetzt extrem Stellung bezogen, ich hoffe das liest jemand, der das ganze Buch mal umkrempelt und sich ein paar Dinge zu Herzen nimmt.

Das funktioniert sowieso nicht. Entweder du machst es selbst, oder niemand.

Aufsplitten des Buches

Ich bin dafür, diese Buch aufzuteilen in (mindestens) zwei verschiedene. Das ursprüngliche Ziel, eine Einführung in das Programmieren zu sein, wurde bisher weit verfehlt. Ein großer Teil ist mehr eine Art Referenz, vor allem an Programmiersprachen. Deswegen wäre ein zweites Buch mit einem Titel der Art "Programmiersprachen und Konzepte" oder "Programmiersprachen und Paradigmen" ganz angebracht, wo all das hinverschoben wird.

Das nächste mal bitte Diskussionsbeiträge unterschreiben, ok? --Bodo Thiesen 14:40, 16. Jul 2005 (UTC)

Warum? Ich habe weder ein Login noch sehe ich den Sinn? Aber ich lass mich gerne eines besseren belehren.

Ich bin eher dagegen. lass doch das Buch komplex werden. Dieses Buch hat den Anspruch, in das Programmieren einzuführen. Es wird sich nachher keiner das Buch über Programmiersprachen durchlesen. Also sollte man die besser hier mit erschlagen. Momentan hat das Buch allerdings tatsächlich ein Ungleichgewicht. Das liegt aber u.a. auch einfach daran, daß man, wenn man über jede Programmiersprache nur ein zwei Absätze schreibt, schnell sehr viel Inhalt erhält, während für die anderen Bereiche jeweil viel mehr zu schreiben ist. Ich denke, dieses Problem wird sich mit der Zeit erledigen, man muß nur aufpassen, daß die Abschnitte über die Programmiersprachen nicht zu sehr vergrößert werden. --Bodo Thiesen 14:40, 16. Jul 2005 (UTC)

Variablennamen nach Sinn und nicht Typ benennen

»5) Variablen nach ihrer Bedeutung und nicht nach ihrem Typ benennen.«

  int i = 5; --> int anzahlHandler = 5;

i steht für den Zweck: i = index oder auch iterator wird (meist) zum indizieren eines Arrays benutzt, in jedem Fall aber, um irgendwas zu zählen (vgl. auch die Verwendung von den Buchstaben i,j,k usw in der Mathematik). Außerdem benutzten fast 100% der Programmierer fast nur die Variablen i,j,k,l (wer mehr braucht macht idR. etwas falsch) in for Schleifen. Wer immer das Beispiel geschrieben hat, hat bewiesen, daß er nich nicht viel Praxiserfahrung beim Programmieren hat, und auch noch nicht viele fremde Quellcodes gelesen hat. Vor allem aber kommt der Buchstabe i nicht aus Zeiten von C sondern wurde auch schon früher benutzt, als der Datentyp noch nicht mal mit i anfing. Ich habe das Beispiel daher mal durch ein Typisches Windoze-Beispiel ersetzt. --Bodo Thiesen 14:36, 16. Jul 2005 (UTC)

Das i stammt vermutlich aus der Fortran-Zeit. Es gibt einen Fortran-Standard, bei dem der Variablentyp defaultmäßig durch den Anfangsbuchstaben festgelet wurde. So waren Variablen, die u.a. mit i, j und k anfingen, so sie nicht explizit definiert waren, integervariablen. Sprich, man konnte, ohne sie zu definieren, sofort als integer-Variablen verwenden. Ähnliches galt für fließkomma-Variablen. Welche Buchstaben zu welchem Typ gehören weiß ich nicht mehr. --Arbol01 01:33, 4. Feb 2006 (UTC)

Sinn des Buches...

Das Buch soll ja eigentlich Leuten, die noch nicht viel mit programmieren zu tun hatten, das Programmieren naeher bringen. Allerdings tut es eher alle moeglichen Programmiersprachen aufzaehlen, aber nicht viel mit ihnen weitermachen. Warum bringt man dem Leser nicht einfach zuerst HTML und C naeher, was man als Grundwissen immer gebrauchen kann, und da beide Sprachen nicht plattformgebunden sind - wie TurboPascal oder aehnliches - fuer alle nutzbar (nicht jeder nutzt Windows). Danach koennte man objekt-orientiertes Programmieren erlaeutern und ein bisschen was zu Java machen, was auch wieder auf jeder Plattform laeuft. Dann koennte man um noch ein Stueckchen weiter zu gehen eine kleine Java-App mit GUI basteln. Als Schlusswort kann man dann dem Leser sagen, dass er jetzt grundlegende Strukturen des Programmierens kennt und dann vielleicht eine Liste vieler Programmiersprachen bringen, bei denen ihre Vor- und Nachteilen kommen. Dazu sollte man zu jeder Sprache vielleicht ein oder zwei Links mit weiterfuehrender Literatur zusammenbringen. Neum 22:31, 23. Jul 2005 (UTC)

Aufteilung auf mehrere Kapitel/Seiten

Ich würde vorschlagen, das Buch auf mehrere Kapitel/Seiten aufzuteilen, weil ich finde, dass es inzwischn zu unübersichtlich geworden ist. Eure Meinungen? --Stefan Kögl 19:58, 7. Aug 2005 (UTC)

Hoffentlich wird es noch was...

Die wenigen Sätze des Buches machen leider überhaupt keinen guten Eindruck. Sind wirklich alle Wikipedia-Bücher so? Dabei finden sich doch wahrscheinlich gerade unter den Wikipedianern viele gute Programmierer. Aber vielleicht verderben ja doch zu viele Köche den Brei, zu viele Gewürze sicherlich. Zum einen mangelt es am sprachlichen Ausdruck. Zum anderen ist mir der Sinn des Buches nicht klar. Eine hochschulgerechte Definitionssammlung für alles und jedes zum Thema Programmierung? Dann viel Glück, verehrte Hobbyprogrammierer. Oder ein Einstieg in die Programmierung für blutige Anfänger? Dann sollte man sich doch lieber auf eine einzige, möglichst weit verbreitete Programmiersprache beschränken. Aber dazu müsste man sich ja notgedrungen einigen ;-) --Sebastian Baltes 20:41, 3. Feb 2006 (UTC)

Zitat >>Sind wirklich alle Wikipedia-Bücher so?<<

Für die Programmierbücher kann man nur mit JA antworten. Fast jedes, der in Ansätzen vorhandenen Programmiersprachen-Bücher hat/hatte den Anspruch, (auch) für Programmiereinsteiger zu sein. Und fast alle der Bücher wurden von Programmiereinsteigern initiiert (z.B. C#, PureBasic, Dark Basic, Python, GTK+ in C), wohl in der irrigen Annahme, dass gerade sie für solche Bücher am besten qualifiziert seinen. Da reichen schon die ersten 2 oder 3 Tage, um zu erkennen, dass das nie etwas wird, zumindest wenn man eine ungefähre Ahnung hat, wie man Bücher schreibt. Und das Ziel sollte ja schon ein konkurrenzfähiges Buch sein.

Warum finden sich keine geeigneten Buchautoren? Keine Ahnung. Ich für mich kann nur sagen: Mir wäre die Zielgruppe - nämlich an Programmierung Interessierte, die auf deutschsprachiges angewiesen sind - zu klein. Zudem: Ich fände es nicht so toll, mein Buch hier zwischen all den Buchruinen stehen zu sehen. Aber die Tendenz geht hier eher in Richtung nicht löschen. --84.131.194.4 22:37, 3. Feb 2006 (UTC)

Wenn Du es besser schreiben kannst? Warum nicht? Ich suche auch Leute, die gut formulieren können. Und was das bisher vorletzte von mir angestoßene Projekt ist REXX, das ist frei. Naja sagen wir fast frei. Man sollte die Beschreibungen zu REXX halt irgendwie noch erkennen. Es ist eben nicht jedem gegeben, ein guter Sachbuchautor zu sein. --Arbol01 9:39, 3. Feb 2006 (UTC)

@Sebastian Baltes: Ein guter Programmierer ist nicht zwangsläufig ein guter Autor von Büchern zur Programmierung. Es ist sogar eher unwahrscheinlich, das ein guter Programmierer gute Programmierbücher schreibt. Umgekehrt ist ein guter Didakt nicht unbedingt ein guter Programmierer. --Arbol01 00:03, 4. Feb 2006 (UTC)

Du hast bestimmt Recht damit, daß ein guter Programmierer nicht zwangsläufig ein guter Autor ist. Ein guter Programmierer zu sein ist für dieses Projekt keine hinreichende, aber in meinen Augen doch zwingend notwendige Bedingung. Genauso verhält es sich mit der Eigenschaft als Autor. Ich möchte auch nicht den Anspruch erheben, es besser zu können. Ich selbst bin beruflich Java-Programmierer, und glaube, daß ich das Kriterium eines guten Programmierers erfülle. Aber ein Autor? Ich vermute aber mal, daß so ein Buch eine wirklich aufwändige und zeitintensive Arbeit ist. Wenn ich mir die Bücherregale anschaue, dann bekommt man für 20 Euro viele gute Bücher angeboten, die genau das Thema Einstieg in die Java-Programmierung behandeln. Also würde ich mir doch zuerst einmal Gedanken über die konkrete Nische machen, in der das Projekt Erfolg haben soll. Eine coole neue Sprache vielleicht, für die es noch nicht so viel gibt wie für Java oder C++? --Sebastian Baltes 20:41, 11. Feb 2006 (UTC)

Was meinst Du, warum ich REXX genommen habe? --Arbol01 10:37, 11. Feb 2006 (UTC)