Contest: Tutorial zum Programmieren eines Taschenrechners

Wie im „Eine-Idee“-Thread ( http://www.multimediaxis.de/showthread.php?t=60590 ) bereits angekündigt, folgt nun die Aufgabenstellung von meiner Seite aus.

Contest: Tutorial zum Programmieren eines Taschenrechners

- Vorwort -

Da sich anscheinend sonst keiner dafür bereit erklärt, den Wettbewerb zu leiten, dachte ich mir, dass die Idee daran nicht scheitern dürfe, einen solchen Contest zu veranstalten.

- Aufgabenstellung -

Kurzform:

Schreibe ein Tutorial für Anfänger zum Programmieren eines Taschenrechners in einer beliebigen Programmiersprache.

Detailreicher:

Es gibt 3 verschiedene Stufen:

Stufe1:
Der Taschenrechner umfasst: Addition, Subtraktion, Multiplikation und Division.

Stufe2:
Stufe1 + Geometrische Flächenberechnung (z.B. Quadrat, Kreis, Drachen)

Stufe3:
Stufe2 + Geometrische Körperberechnung (z.B. Quader, Kugel, Zylinder, Kegel)

Bei Stufe 2 und 3 steht es dem Wettbewerbsteilnehmer frei, in wiefern er die Berechnungen umsetzt und welche er integriert.

Grundsätzlich gilt, dass der spätere Benutzer des Programms 2 Zahlen selbst eingeben kann und dazu die gewünschte Rechenart wählt. Darauf soll entweder eine Schaltfläche mit einem „=“ oder ähnlicher Bedeutung zur Verfügung stehen. Wird diese (oder vll. [Enter]) betätigt, so wird das Ergebnis der Rechnung angezeigt.
Wie das im Einzelnen bei Stufe 2 und 3 aussieht, bleibt, wie bereits erwähnt, dem Teilnehmer überlassen.

Es kann jede Programmiersprache benutzt werden. Die spätere Programmoberfläche ist ebenso frei wählbar. Damit ist vor allem das Äußere gemeint.

Zitat:

---

1. Konsolen-Apps sind zugelassen
Je nach gewählter Sprache, kann das Programmieren einer GUI recht aufwendig und kompliziert werden. Das widerspricht aber dem Prinzip eines Anfängerfreundlichen Tutorials. GUI-Programmierung per WinAPI oder Toolkit kann ich nicht vorraussetzen, weil die Leute, die sowas bedienen können, auch einen Taschenrechner aus dem Ärmel schütteln können. Wenn ich aber die GUI-Programmierung mit ins Tutorial reinnehme sprengt das den Rahmen und ist mit großer Wahrscheinlichkeit eher abschreckend für die Leser.
Sicher ist die Bedienbarkeit eines Taschenrechners per GUI besser als einen, den man per Konsole bedienen muss, aber es geht hier ja um die Programmierung und die darin verwendeten Technicken, nicht darum ein möglichst gutes Endprodukt zu produzieren.
Dem Teilnehmer sollte also freigestellt werden, ob er ein Tut für einen GUI- oder einen Konsolenrechner schreibt. Das kann dann natürlich bei der Bewertung eine Rolle spielen. GUI-Programme wirken besser auf Anfänger da sie "was zum Anfassen" sind. Ein Tutorial was einem einfach die Erstellung eines solchen Programmes vermittelt ist attraktiver als das "abstrakte" Konsolen-Tut. Alternativ und je nachdem wieviele Einsendungen es gibt, kann man Konsolen und GUI-Tuts ja getrennt bewerten.

2. Die Testbarkeit
Ich würde sagen, Windows wird als Standard-Test Umgebung verlangt. Programmieranfänger, für die das Tut ja gedacht ist, haben mit Sicherheit kein Linux laufen. Die linux-only User hier können ja gucken ob sie die einfachen Windowsprogramme auch per WINE ans laufen kriegen..
Sollte für das Ausführen des Programmes externe Programme oder Bibliotheken benötigt werden, so sind diese vom Teilnehmer zu verlinken/bereit zu stellen. Geringe Abhängigkeit oder die Möglichkeit die Dinger statisch in die Binary reinzubinden sind aber letztendlich auch wieder Pluspunkte. Weniger Kram zu installieren => Attraktiver für den Anfänger.
Bei PHP, sollte das Programm auf einem laufenden PHP-Server liegen und verlinkt sein, so daß zumindest die fehlerfreie Funktionalität ohne zusätzliche Installation getestet werden kann.

3. Was setze ich vorraus?
Ein Tutorial für einen Taschenrechner hat mMn nur zwei Arten von Zielgruppen.
a) Den totalen Anfänger
Keinerlei Erfahrung mit Programmierung oder ähnlichem.
b) Den Anfänger
Hello-World und vielleicht Eingabe-Antwort Programm in der Sprache des Tutorials absolviert.
Welchen der beiden ich als Teilnehmer anpeile, bleibt mir überlassen. Wichtig ist natürlich, daß ein schlankeres Tutorial meistens besser ankommt als eine riesige Textflut.

---

Reine Dosanwendungen, also rein textorientierte Programme, sind jedoch nicht wünschenswert.

Das Tutorial ist in Form einer Text oder *.html Datei abzugeben (also inkl. HTML, PDF und Office Dokumente/Works/OpenOffice.org).
Dabei sollte besonders darauf geachtet werden, dass es ein Anfänger versteht, der also noch nie etwas mit der jeweiligen Sprache gemacht hat; dass die Rechtschreibung einigermaßen akzeptabel ist; dass es einer vernünftigen Reihenfolge nachkommt; dass mögliche Quellen angegeben werden und dass es quasi die eigene Großmutter versteht (nur noch mal erwähnt, um die anfängerfreundliche Schreibung hervorzuheben).

Zitat:

---

mehr als Grundlagen in der GUI Programmierung sollte nicht erklärt werden müssen, .

---

Zu dem Tutorial soll ein eigener Taschenrechner mitbeigelegt werden, der funktionstüchtig und das mögliche Ergebnis des Tutorials festhält.

Es kann jeder mitmachen, der meint, ein verständliches und selbsterstelltes Ergebnis präsentieren zu können.

- Jury? -

Am Ende des Wettbewerbs wird eine Umfrage den Sieger bestimmen.

- Termine -

Der Contest beginnt ab sofort und endet am 07.12.2005.
Damit sollte genügend Zeit gegeben sein, nicht nur ein anständiges Programm, sondern auch ein dazugehöriges Tutorial zu verfassen.
Bis zum 07.12., 23:59 Uhr, sollen die Tutorials mit den dazugehörigen Programmen hier veröffentlicht werden.
Danach wird kein Tutorial mehr zum Wettbewerb zugelassen.
Die Umfrage wird kurze Zeit später folgen und endet nach 2-3 Wochen.

- Sonstiges -

Wenn noch weitere Fragen bestehen, hoffe ich, dass diese baldmöglichst gestellt werden, um Missverständnissen aus dem Weg zu gehen.
Die so ziemlich freien Möglichkeiten sollen nicht davon ablenken, dass ein totaler N00b im Programmieren das Endprodukt, also das Tutorial, verstehen können soll. (toller Satz ^^)

Jeder Teilnehmer kann nur ein Tutorial einreichen.

Dies ist meine erste selbstverfasste Aufgabenstellung, deswegen seid mir nicht all zu böse, wenn irgendetwas noch nicht so klar sein sollte.

Und jetzt: Fangt an!

Uff. Ein Taschenrechner zu programmieren ist eine Sache, aber einem totalen Neuling (wie du es gesagt hast) dies zu erklären ist eine ganz andere... Mal sehen ob ich das einplanen kann, sind ja bald Ferien.

Zitat:

---

Zu dem Tutorial soll ein eigener Taschenrechner mitbeigelegt werden, der funktionstüchtig und das mögliche Ergebnis des Tutorials festhält.

---

Das verstehe ich noch nicht so ganz. Ist Mit eigener Taschenrechner die compilierte Version des Tutorial Taschenrechners gemeint?


Und soll der Taschenrechner auch grafisch gestaltet sein? Und darf man dafür Grafikdateien dem Tutorial hinzufügen?

Mit dem beigelegten Taschenrechner ist eine compilierte Version des Tutorialprogramms gemeint, ja.

Zitat:

---

Die spätere Programmoberfläche ist ebenso frei wählbar.

---

Damit ist auch die grafische Gestaltung gemeint. Wenn es dadurch nötig wird, Grafikdateien beim Tutorial mitzuliefern, ist dies gestattet.

Ich hoff aber doch mal, dass wir nicht noch extra was eine Variable oder eine Klasse ist, oder?

Zitat:

---

Zitat von DFYX

Ich hoff aber doch mal, dass wir nicht noch extra was eine Variable oder eine Klasse ist, oder?

---

anfänger tutorial ;)

ne, du könntest zb grundvoraussetzungen für das, was man können sollte angeben, möglicherweise auf ein totales anfängertutorial verweisen, wäre ne elegante lösung, imo.

oder du erklärst sowas einfach nicht und setzt es voraus. das ist dann natürlich nicht mehr 100% anfängerkram...

Auf welchem Betriebssystem muss das Ding mindestens laufen? Ich würde mich da ja wenigstens auf Windows festlegen, weil das immer noch das meist genutzte OS ist. Und die Jury (die Community welche wählt) muss ja auch fähig sein, dass Programm in Augenschein zu nehmen. Und nicht jeder hat Mac OS oder Linux zur Hand.

Was mir Bedenken macht ist die Aussage, dass es ein Newbie ohne Vorkentnisse dieser Sprache oder die eigene Oma können muss. Da sind die Möglichkeiten gleich viel eingegrenzter.

Hm, interessant. Ich merke gerade, dass ich bisher immer übersehen hab, dass es auch um Tuts geht, nicht nur ums Programmieren.
Ich weiß noch nicht, ob ich mitmache, ich bin nicht unbedingt ein guter Tutorialschreiber und hab momentan viel um die Ohren.

Hm, das ist interessant. Ich lese zum Glück viele Tutorialbücher, da wird es beim Formulieren (hoffentlich) keine Schwierigkeiten bei mir geben. Mit satten 2 Monaten Zeit können IMO sogar "Trödler" fertig werden (wenn ich es bis dahin geschafft habe, wird das stimmen :D ). Leider hab' ich kaum Erfahrung mit fortgeschrittener Mathematik (konnte man mal abwählen, was ich Depp auch gemacht habe :rolleyes: ), weshalb ich mich wohl mit Stufe 1 begnügen muss. Höchstens noch Stufe 2, aber bei Stufe 3 hab' ich keine Ahnung.

Zitat:

---

Reine Dosanwendungen, also rein textorientierte Programme, sind jedoch nicht wünschenswert.

---

Bin ich froh, dass ich mich endlich von QBasic verabschiedet habe^^.

Ich bleib' weg. Ich müßte einem Neuling erst mal das gesamte Konzept von Programmiersprachen, dann das gesamte Konzept von OOP, dann die Grundprinzipien vonn Java und dann Swing erklären, bevor ich überhaupt auf den Matheteil kommen würde - das wären bei einem guten Tutorial zwischen 10 und 30 Seiten nur für Abhängigkeiten. Muß nicht sein.

Wenn Textprogramme erlaubt wären könnte man das Ganze viel einfacher machen (allein durch die Verwendung von PHP könnte ich 80% der Arbeit einsparen), aber so habe ich weder die Zeit noch die Geduld noch die Energie, um eine Buchstabenwüste zusammenzutippen, nur um hinterher zu sagen: "So, und jetzt fasse ich das eigentliche Thema dieses Tutorials in zwanzig Zeilen zusammen".

Für n' neuling wäre mir das auch zu viel. Für jemanden der schon die Grundfunktionen der entsprechenden Sprache kann, also etwa (Hello-World oder Gib-deinen-Namen-ein-und-ich-sag-Hallo-zu-dir- Anwendungen entwickeln kann)

Meine Situation ist ähnlich wie die von Jeez - ich hab nicht wirklich Zeit und Lust dazu, irgendjemanden OOP und Java zu erklären. Die Grundlagen von Swing wären noch drin, aber mehr wohl nicht.
Vielleicht progge ich aus Spaß 'nen Rechner ohne wirkliches Tut. Mal sehen.

Eben aus dem Grund hab ich gefragt. Ich denk, mehr als Grundlagen in der GUI Programmierung sollte nicht erklärt werden müssen, sonst wirds zu viel.

Wer dafür ist, den Contest entsprechend anzupassen, möge bitte die Hand heben *heb*

*heb*

*heb*

*heb*

ich probier mich mal mit PureBasic.
Mal sone frage kann man nicht einfach auch den Quellcode komentieren?

Zitat:

---

Zitat von MJcoox

ich probier mich mal mit PureBasic.
Mal sone frage kann man nicht einfach auch den Quellcode komentieren?

---

Glaubst du, ein kommentierter Quellcode kann ein Tutorial ersetzen?
Wenn du da wirklich neue Sachen erklären willst, musst du auch einen ähnlch ausführlichen Text als Kommentar schreiben - da kannst du das gleich extern machen, das erhöht die Übersicht.

ja werd ich auch machen, mit der .txt datei.

Wollte nur fragen ob es auch so möglich ist.

Hrm... joa, also wegen PHP wurde ich auch noch mal per PN angeschrieben ...
Stelle man sich jetzt jemanden vor, der nicht weiß, wie er PHP bei sich installiert, ich meine, der muss das Tut doch auch irgendwie nachvollziehen können.
Es sollte möglichst ein eigenständiges Programm herauskommen, dass also dann schon Compiliert ist.
(gibt es eigentlich Interpreter, die *.exe erzeugen?)

Zitat:

---

mehr als Grundlagen in der GUI Programmierung sollte nicht erklärt werden müssen, sonst wirds zu viel.

---

Ergänze ich gleich.

Zitat:

---

Zitat von Niji-chan

Hrm... joa, also wegen PHP wurde ich auch noch mal per PN angeschrieben ...
Stelle man sich jetzt jemanden vor, der nicht weiß, wie er PHP bei sich installiert, ich meine, der muss das Tut doch auch irgendwie nachvollziehen können.
Es sollte möglichst ein eigenständiges Programm herauskommen, dass also dann schon Compiliert ist.
(gibt es eigentlich Interpreter, die *.exe erzeugen?)

---

Im Gegensatz zu C++, das man auf jedem Rechner kompilieren kann? Selbst unter Linux hat nicht jeder User die GCC installiert - oder weiß, wie man sie benutzt. Man kann also entweder voraussetzen, daß der Leser für einen Compiler/Interpreter schon gesorgt hat und damit umgehen kann oder man muß in das Tutorial zusätzlich noch Informationen darüber aufnehmen, wie man an die benötigte Software rankommt, wie man sie installiert und wie man sie benutzt (zumindest in Grundzügen).

Mir fällt gerade auf, daß diese Contest sich so langsam in die gleiche Richtung entwickelt wie der letzte: Bei einem Gedankengang wurde ein möglicher Fehler übersehen und alle potentiellen Teilnehmer tun ihr bestes, um ein worst case-Szenario sicherzustellen.
Um zu vermeiden, daß der contest unschaffbar wird und/oder alle abspringen empfehle ich dringend, den Zusatz "für Anfänger" aus der Spezifikation zu streichen oder abzuschwächen.

Zitat:

---

Zitat von Jesus_666

Im Gegensatz zu C++, das man auf jedem Rechner kompilieren kann? Selbst unter Linux hat nicht jeder User die GCC installiert - oder weiß, wie man sie benutzt. Man kann also entweder voraussetzen, daß der Leser für einen Compiler/Interpreter schon gesorgt hat und damit umgehen kann oder man muß in das Tutorial zusätzlich noch Informationen darüber aufnehmen, wie man an die benötigte Software rankommt, wie man sie installiert und wie man sie benutzt (zumindest in Grundzügen).

Mir fällt gerade auf, daß diese Contest sich so langsam in die gleiche Richtung entwickelt wie der letzte: Bei einem Gedankengang wurde ein möglicher Fehler übersehen und alle potentiellen Teilnehmer tun ihr bestes, um ein worst case-Szenario sicherzustellen.
Um zu vermeiden, daß der contest unschaffbar wird und/oder alle abspringen empfehle ich dringend, den Zusatz "für Anfänger" aus der Spezifikation zu streichen oder abzuschwächen.

---

macht doch einfach "für fortgeschrittene anfänger"
andererseits ist die definition eigentlich gar nicht nötig sein..das tutorial soll ja nur verständlich und nachvollziehbar sein, nicht der weisheit letzter schluss.
und dann sollten sich die leute einfach hinsetzen und gucken, was sie aus der aufgabe machen können...kann ja jeder dann dran ruminterpretieren, für sich selber.

bezüglich PHP nochmal:
Ich meine, das Programm, dass man mit dem Tut abgibt, sollte ein eigenständig laufendes welches sein.
Wenn das Programm aber PHP braucht, ist dem ja eigentlich nicht so.

Zitat:

---

Zitat von Niji-chan

bezüglich PHP nochmal:
Ich meine, das Programm, dass man mit dem Tut abgibt, sollte ein eigenständig laufendes welches sein.
Wenn das Programm aber PHP braucht, ist dem ja eigentlich nicht so.

---

Wenn man eine bestimmte Sorte Binary abgibt bzw. ein bestimmtes Toolkit bzw. eine bestimmte API benutzt, braucht man ein bestimmtes Betriebssystem bzw. eine bestimmte Bibliothek.
Mh?

Zumal damit sowohl Java als auch Visual Basic als auch Visual C++ als auch alle Dotnet-Sprache und wahrscheinlich auch Delphi ausscheiden, weil die alle eine Runtime benötigen. Die verwendbaren Sprachen wären damit auf ANSI-C und ISO-C++ begrenzt.

is doch eh blödsinn, warum sollte jemand, der eine bestimmte sprache lernen will nicht die mittel haben, diese auch auszuführen?
das is als wenn ich mir ein photoshop tutorial durchlese aber gar keine möglichkeit habe, das programm zu benutzen -_-

vor allem da es ja jetzt scheinbar eher um "fortgeschrittene anfänger" geht...

Ich meine, wir wollen die Programme der anderen ja auch irgendwie testen.
Wenn ich jetzt aber keine Lust habe, mir dazu extra noch etwas zu installieren, es geht jetzt wirklich nur um die Programme, fällt das wohl eher nachteilig bei der Bewertung von meiner selbst aus.

Die Tuts werde ich natürlich dann lesen, denn um die geht es ja im Endeffekt, aber ob ich dann wirklich z.B. 3-4 Taschenrechner in verschiedenen Sprachen mit jeweiligen Bedingungen nach Anleitung basteln werde, bin ich mir nicht so sicher drüber.

---

Schreibt die Tuts verständlich.
Nehmt eine Sprache eurer Wahl.
Lasst mich das Ergebnis, ohne großen Aufwand (klar, "groß" ist auch relativ...), mit meinem Windowsrechner sehen können.

Zitat:

---

Zitat von Niji-chan

Ich meine, wir wollen die Programme der anderen ja auch irgendwie testen.
Wenn ich jetzt aber keine Lust habe, mir dazu extra noch etwas zu installieren, es geht jetzt wirklich nur um die Programme, fällt das wohl eher nachteilig bei der Bewertung von meiner selbst aus.

Die Tuts werde ich natürlich dann lesen, denn um die geht es ja im Endeffekt, aber ob ich dann wirklich z.B. 3-4 Taschenrechner in verschiedenen Sprachen mit jeweiligen Bedingungen nach Anleitung basteln werde, bin ich mir nicht so sicher drüber.

---

Schreibt die Tuts verständlich.
Nehmt eine Sprache eurer Wahl.
Lasst mich das Ergebnis, ohne großen Aufwand (klar, "groß" ist auch relativ...), mit meinem Windowsrechner sehen können.

---

Und die Linuxer die nur für Linux was erstellen wollen? http://www.multimediaxis.de/images/s...old/1/ugly.gif

@PHP: Das kann derjenige ders abgibt ja auch auf seinem Webserver laufen lassen. ;)

Dennis

Dennis, es gibt durchaus PHP-Bindings für diverse GUI-Tookits (z.B. GTK und WInAPI, afaik).

Zitat:

---

Zitat von Jesus_666

Zumal damit sowohl Java als auch Visual Basic als auch Visual C++ als auch alle Dotnet-Sprache und wahrscheinlich auch Delphi ausscheiden, weil die alle eine Runtime benötigen. Die verwendbaren Sprachen wären damit auf ANSI-C und ISO-C++ begrenzt.

---

Habe ich nicht mitbekommen, dass Assembler Programme neuerdings ein Runtime Environment brauchen oder habe ich deinen Beitrag falsch verstanden? Meiner Meinung nach gibt es noch etliche andere verwendbare Sprachen außer den von dir genannten.
Also ich hätte nichts dagegen, dass man nur Programme abliefern darf, die ohne zusätzliche Runtime's etc. laufen. Dass die Programme trotzdem an ein Betriebssystem gebunden sind ist klar. Das sollte unter Windows aber auch keine Probleme geben, solange man einfach nur die Win-Api nutzt. Also kernel32.dll und user32.dll sollte wohl jeder halbwegs vernünftige Windows-Rechner haben, denke ich ...

freundliche Grüße, Rolus

Zitat:

---

Zitat von Rolus

Habe ich nicht mitbekommen, dass Assembler Programme neuerdings ein Runtime Environment brauchen oder habe ich deinen Beitrag falsch verstanden? Meiner Meinung nach gibt es noch etliche andere verwendbare Sprachen außer den von dir genannten.
Also ich hätte nichts dagegen, dass man nur Programme abliefern darf, die ohne zusätzliche Runtime's etc. laufen. Dass die Programme trotzdem an ein Betriebssystem gebunden sind ist klar. Das sollte unter Windows aber auch keine Probleme geben, solange man einfach nur die Win-Api nutzt. Also kernel32.dll und user32.dll sollte wohl jeder halbwegs vernünftige Windows-Rechner haben, denke ich ...

freundliche Grüße, Rolus

---

Es gibt einige - aber alle interpretierten Sprachen fallen damit von vorneherein weg. Assembler auch, weil kein geistig gesunder Mensch ein GUI-Programm in Assembler schreibt. Und alle etwas weniger bekannten Sprachen an sich auch, weil es da meist keine Compiler gibt - oder nur welche in Sprachen, die ihrerseits interpretiert sind oder eine Runtimebibliothek brauchen.
Man kann wohl davon ausgehen, daß nur die Sprachen verwendet werden können, die die GCC in der Version 3.4 kompilieren kann - das sind C, C++, Objective-C, Fortran und Ada. Java geht wohl nicht, weil man dafür zum Arbeiten GNU Classpath benötigen würde, was wohl unter die Runtimeklausel fällt.

Des Weiteren würden damit C und C++ nur dann verwendet werden können, wenn zur Grafikausgabe ausschließlich die WinAPI (oder ein komplett selbst geschriebenes Toolkit) genutzt wird - und ich bezweifle, daß die User hier, die sich nie mit der WinAPI befaßt haben (und teilweise nicht mal ein windows zur Hand haben), mal eben schnell lernen, mit einem GUI-Toolkit zu arbeiten, mit dem sie sonst nie etwas zu tun haben.

Um ehrlich zu sein ist die WinAPI wirklich das letzte GUI-Toolkit, das ich jemals anfassen würde. Da würde ich eher für Cocoa schreiben. (Begründung: Die WinAPI ist codetechnisch ziemlich häßlich, unportabel und für ein Betriebssystem, das ich nur zur Abwärtskompatibilität überhaupt noch laufen habe.)

Daß C++ auch eine Runtimebibliothek braucht (für die STL) lasse ich mal außen vor, weil diese Bibliothek überall vorhanden sein sollte.


@mq: Das Kunststück ist, die zum Laufen zu kriegen.

Delphi < 8 braucht keine Runtime. Da braucht man nur die Exe-Datei mehr nicht, bibliotheken sind alle mit ind er Exe (weshalb sie schon bei einem leeren Fenster ~ 200 kb groß ist). Lässt sich mit UPX opimieren.

Okay, man kann C++ auch benutzen, wenn man als Toolkit FLTK verwendet, das wird statisch mit reinkompiliert. Ansonsten ist mir kein Toolkit bekannt, das das fertigbringt.

Zitat:

---

Zitat von Jesus_666

Assembler auch, weil kein geistig gesunder Mensch ein GUI-Programm in Assembler schreibt.

---

Hey, keine Beleidigungen bitte. Assembler und Win-API ist eigentlich eine nette Mischung. Gut, der Code ist unschön, bringt OOP-Fans zum Kotzen und ist in der Regel extrem lang. Aber die Programme sind grundlegend, klein, schnell und mächtig (oder können es zumindest sein). Für manche Bereiche ist es jedenfalls recht praktisch.

Zitat:

---

Zitat von Jesus_666

Um ehrlich zu sein ist die WinAPI wirklich das letzte GUI-Toolkit, das ich jemals anfassen würde. Da würde ich eher für Cocoa schreiben. (Begründung: Die WinAPI ist codetechnisch ziemlich häßlich, unportabel und für ein Betriebssystem, das ich nur zur Abwärtskompatibilität überhaupt noch laufen habe.)

---

Ich möchte eigentlich keine Diskussion über Begriffsdefinitionen führen, aber die Win-API würde ich nicht als Toolkit bezeichnen. Die Win32-API ist die Programmierschnittstelle von Windows. Eigentlich jedes Windows Gui-Toolkit - und die damit erstellten Programme - greifen auf die Win-API zurück. Von daher ist es gar nicht so abwegig, sich mit der grundlegenden Win-API direkt zu beschäftigen.
Btw, Windows ist nunmal noch das meist verwendete Betriebsystem. Man sollte vor lauter Torten das Brot nicht vergessen, denke ich. Den Windows-Bezug als Argument gegen die Win-API zu nennen ist doch etwas über-subjektiv, oder nicht?

freundliche Grüße, Rolus

So, anstatt jetzt darüber zu debatieren wie schlimm oder wie einschränkend denn jetzt die ganzen Sachen sind, mal ein konstruktiver Vorschlag (samt Begründung) von mir:

1. Konsolen-Apps zulassen
Je nach gewählter Sprache, kann das Programmieren einer GUI recht aufwendig und kompliziert werden. Das widerspricht aber dem Prinzip eines Anfängerfreundlichen Tutorials. GUI-Programmierung per WinAPI oder Toolkit kann ich nicht vorraussetzen, weil die Leute, die sowas bedienen können, auch einen Taschenrechner aus dem Ärmel schütteln können. Wenn ich aber die GUI-Programmierung mit ins Tutorial reinnehme sprengt das den Rahmen und ist mit großer Wahrscheinlichkeit eher abschreckend für die Leser.
Sicher ist die Bedienbarkeit eines Taschenrechners per GUI besser als einen, den man per Konsole bedienen muss, aber es geht hier ja um die Programmierung und die darin verwendeten Technicken, nicht darum ein möglichst gutes Endprodukt zu produzieren.
Dem Teilnehmer sollte also freigestellt werden, ob er ein Tut für einen GUI- oder einen Konsolenrechner schreibt. Das kann dann natürlich bei der Bewertung eine Rolle spielen. GUI-Programme wirken besser auf Anfänger da sie "was zum Anfassen" sind. Ein Tutorial was einem einfach die Erstellung eines solchen Programmes vermittelt ist attraktiver als das "abstrakte" Konsolen-Tut. Alternativ und je nachdem wieviele Einsendungen es gibt, kann man Konsolen und GUI-Tuts ja getrennt bewerten.

2. Die Testbarkeit
Ich würde sagen, Windows wird als Standard-Test Umgebung verlangt. Programmieranfänger, für die das Tut ja gedacht ist, haben mit Sicherheit kein Linux laufen. Die linux-only User hier können ja gucken ob sie die einfachen Windowsprogramme auch per WINE ans laufen kriegen..
Sollte für das Ausführen des Programmes externe Programme oder Bibliotheken benötigt werden, so sind diese vom Teilnehmer zu verlinken/bereit zu stellen. Geringe Abhängigkeit oder die Möglichkeit die Dinger statisch in die Binary reinzubinden sind aber letztendlich auch wieder Pluspunkte. Weniger Kram zu installieren => Attraktiver für den Anfänger.
Bei PHP, sollte das Programm auf einem laufenden PHP-Server liegen und verlinkt sein, so daß zumindest die fehlerfreie Funktionalität ohne zusätzliche Installation getestet werden kann.

3. Was setze ich vorraus?
Ein Tutorial für einen Taschenrechner hat mMn nur zwei Arten von Zielgruppen.
a) Den totalen Anfänger
Keinerlei Erfahrung mit Programmierung oder ähnlichem.
b) Den Anfänger
Hello-World und vielleicht Eingabe-Antwort Programm in der Sprache des Tutorials absolviert.
Welchen der beiden ich als Teilnehmer anpeile, bleibt mir überlassen. Wichtig ist natürlich, daß ein schlankeres Tutorial meistens besser ankommt als eine riesige Textflut.

Der Sinn dieses Contestes ist es aus meiner Sicht zumindest, das wir einige nette Anfänger-Tutorials kriegen, insbesondere in verschiedenen Sprachen. Es geht hier weder darum etwas zu gewinnen (ausser bisl Ehre vielleicht), noch dazu sein Ego irgendwie aufzupolieren. Daher habe ich zumindest kein Problem damit, die Fairness eines Contests, dem Wunsch nach sinnvollen Tutorials unterzuordnen.

Einwände, Kommentare, Beifallbekundungen?

Volle Zustimmung, mit dem Zusatz, dass z.B. Java eh auf beinahe jedem Rechner installiert ist.

Wenn das Tutorial als reinen Text als Txt Datei abzugeben ist sind also keinerlei Bilder erlaubt... Das finde ich ein bisschen schade, besonders weil gerade Bilder ein Tutorial erst verständlich gestalten. Wie wär's stattdessen, wenn das Tutorial alternativ auch in html abzugeben wär? Also eine simple Website mit beigefügen Bildern wobei nicht die Website sondern nur das Tutorial als Bewertungskriterium herangezogen wird. Sprich, der Quellcode der Website ist wurscht, wie wirr der Sein mag, wenn das Tutorial gut aufgebaut ist.

Und weiter geht das Handhebespielchen *heb* Bin eindeutig dafür, dass HTML, PDF und Office Dokumente (MS Office und OpenOffice) erlaubt sind. Schon allein, damit man saubere Formatierungen hat.

Ich finde zwar gerade nicht den Ort, wo ich gesagt habe, dass ich eine *.txt möchte, aber egal.
Ich stimme MagicMagor zu und edite gleich erstmal ein Zitat.

Wegen *.HTML, *.PDF und *.DOC, *.WPS und *.SXW ... halte ich auch wegen dem Bildzusatz für sinnvoll.
Besonders bei *.html ist eine übersichtliche Darstellungsmöglichkeit gegeben.
Deswegen edit ich das gleich auch noch hinzu.

Hm. Office-Dokumente sollte man evtl. wegen der Kompatibilität nicht benutzen - MS Office-User können keine OOo-Dokumente öffnen, und ich hab auch schon hässliche Fehler beim .doc-Export von OOo gesehen. Ich würde auf Plain Text, HTML und PDF beschränken, das sollte jeder öffnen können.

@ Rolus:
Assembler setzt eine Prozessorarchitektur vorraus. Demnach hat es mehr Abhängigkeiten als ANSI-C *nur mal so anmerk*

Zitat:

---

Zitat von masterquest

Hm. Office-Dokumente sollte man evtl. wegen der Kompatibilität nicht benutzen - MS Office-User können keine OOo-Dokumente öffnen, und ich hab auch schon hässliche Fehler beim .doc-Export von OOo gesehen.

---

Dafür gibt's doch auch diese Office-Viewer von MS. Allerdings hätten damit wohl die "Linuxer" ein Problem, weil die Viewer nur unter (ihr ahnt es schon^^) Windows-OSsen laufen...

Öhm... Niji-chan, ich stehe wegen deinem derzeitigen Anfangspost gerade auf dem Schlauch. Du zitierst einerseits MagicMagor mit "Dem Teilnehmer sollte also freigestellt werden, ob er ein Tut für einen GUI- oder einen Konsolenrechner schreibt.", schreibst aber gleich unter seinem Zitat "Reine Dosanwendungen, also rein textorientierte Programme, sind jedoch nicht wünschenswert." Wie jetzt genau, wolltest du damit den Post von MagicMagor beantworten oder "ergänzen"? Letzteres kann's wohl nicht sein.^^

Afaik kommt der Satz mit den DOS-Anwendungen aus der ersten Regelfassung; der Teil von Magor sollte also aktueller sein.

is noch von vorher das mit dem Dos zeugs...

hrm, joa,... soll ichs rausnehmen ;) :D ?

Beim Dokumentenformat würde ich Plaintext/BBCode, HTML und PDF ganz klar bevorzugen - zumal es wirklich kein Problem ist, mit der Office-Anwendung seiner Wahl (Microsoft Office benötigt Zusatzsoftware) nach PDF zu exportieren. Allein schon deshalb, weil der Acrobat Reader (respektive Anzeigesoftware für OS X und Linux) weiter verbreitet ist als (Open)Office.

Magor Vorschlag würde ich auch zustimmen, wobei ich eine Java-Runtime auch als installiert voraussetzen würde.
Wenn das GUI-Toolkit nicht festgelegt ist bietet das auch die Möglichkeit, plattformunabhängig zu arbeiten - das ist praktisch für Linux-Anwender, die dann keinen Cross-Compiler installieren müssen, weil WINE PEs erwartet. Das wurde von Magor sauber gelöst - man verweist einfach auf alle benötigten Bibliotheken, gibt Anweisungen zur Installation und gut ist.