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?)
Ergänze ich gleich.Zitat
--
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.
--
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?
--Abwesend.
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.
Geändert von Jesus_666 (07.10.2005 um 20:42 Uhr)
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.
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.
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
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.
--
Und die Linuxer die nur für Linux was erstellen wollen?
@PHP: Das kann derjenige ders abgibt ja auch auf seinem Webserver laufen lassen.
Dennis
--«Wir können alles schaffen, wir brauchen nur genug dressierte Affen» - infinite monkey theorem
Dennis, es gibt durchaus PHP-Bindings für diverse GUI-Tookits (z.B. GTK und WInAPI, afaik).
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.
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.
--
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*
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.^^
Berechtigungen
Zitieren
