Archiv der Kategorie: C

Datenfeldstudien

Dank des zärtlichen, solidarischen Drucks, den die Featurette neuerdings auf mich ausübt, sollte ich nicht allzu lange den nächsten Blogpost vor mir herschieben. (Vielen Dank nochmal, Kadda!)
Allerdings lässt sich das, was ich mitteilen möchte und zukünftig wohl auch werde eher schwer in die bisherigen Kategorien einordnen. Es ist viel geschehen, aber statt eure Reader mit 10 kleinen Posts zu füttern, arbeite ich jetzt einfach die Themen in einem Post ab.

Als Erstes der Leistungsnachweis, Freunde und Freundinnen der Leistungsgesellschaft! Wie steht es um C? Die letzten Kapitel, die ich durchgearbeitet habe handelten von Feldern, Zeichenketten (Kapitel 7 aus “C – Programmieren von Anfang an”, Erlenkötter) und Variablen und Konstanten (Kapitel 8).

Datenfelder

Durch Datenfelder (engl. arrays) lassen sich Variablen definieren, unter deren Namen mehrere Werte gespeichert sind. Zum Beispiel

double temperatur[31]

für die Temperaturwerte eines Monats. Ich kann natürlich auch für die Temperaturdurchschnittsformal august1+august2+august3…usw. schreiben, weil ich z.B. den August ganz besonders mag. Ich kann aber auch so ein Feld verwenden und mir und allen LeserInnen wertvolle Augustzeit schenken. Hier wurden 31 Plätze für Zeichen des Typs double reserviert. Allerdings rufe ich den Wert des 03. Augusts (Der Geburtstag von Martin Sheen, Martha Stewart und vermutlich vielen mehr) mit august[2] auf, da selbstverständlich die erste Indexnummer in C bei 0 beginnt.

Zeichenketten sind auch ein Datenfeld, allerdings vom Typ char und sie speichern Texte. Wenn ich im Programm die User dazu auffordere, ihr Lieblingswort einzugeben, kann ich mit der Funktion “gets” den Satz in das Datenfeld einfügen. Das sieht dann bspw. so aus:

#include <stdio.h>
#include <string.h>                                                  /*(1)/

main()
{
        char wort[20];                                                /*(2)/   
        printf("\nGuten Morgen Tim, was ist dein Lieblingswort?\n");
        gets(wort);                                                  /*(3)/ 
        printf("\n%s", wort);                                        /*(4)/ 
}

(1) Die Datei string.h wird benötigt, sobald Funktionen zur Verarbeitung von Zeichenketten eingesetzt werden.
(2) Hier werden 20 Zeichen reserviert für den Text, der eingelesen werden soll. Wenn ich aber tatsächlich ein Wort mit 20 Zeichen eingeben möchte, z.B. “Amphetaminmissbrauch”, müsste ich 21 Zeichen reservieren, da ein Platz für die reserviert ist.
(3) Die Funktion gets liest den eingegebenen Satz und gibt in in das Datenfeld ein. Außerdem kümmert sie sich um die winkende Null.
(4) Unschwer zu erkennen, dass %s der Plathalter für die Zeichenketten, also “strings” ist.

Das Zeichenfeld hat jetzt vier Zeichen gespeichert:

 0    1    2    3    4
 E    p    i    ḱ    "\ 0"

Das Programm gibt aber nur so viele Zeichen aus, bis es die binäre Null am Ende findet.
/’ Dieses Beispiel beruht auf einer wahren Geschichte. /

Es gibt noch weitere Funktionen mit denen die Zeichenketten kopiert, verknüpft und verglichen werden können. Eine schöne Übersicht gibt es hier.

Variablen Vol. 9000

Im Achten Kapitel wird nochmal das Thema Variablen aufgegriffen. Die Grunddatentypen char, int, float und double können durch die Modifizierer unsigned, signed, short und long deklariert werden. Manchmal ist das notwendig, wenn die Datentypen für eine bestimmte Aufgabe zugeschnitten werden müssen.
Als Beispiel: Der Unterschied zwischen einem signed char und einem unsigned char liegt in den Bereichen von Minimalwert bis Maximalwert. Der Minimalwert von einem signed char liegt bei -128 und der Maximalwert bei 127. Bei einem unsigned char erstreckt sich die Bandbreite von 0 bis 255. Allerdings nimmt der Compiler standardmäßig an, dass die Typen vorzeichenbehaftet sind, deswegen reicht auch char ohne Modifizierer von -128 bis 127.

Weiterhin weist der Autor im Kapitel darauf hin, dass man bei der Bildung von geschweiften Klammern darauf achten muss, dass sie die Gültigkeit von Variablen einschränken. Wird eine Variabel innerhalb der Klammer definiert, so gilt diese Definition auch nur dort. Außerhalb muss sie erneut deklariert werden. Eine Variable, die nur innerhalb einer Funktion verwendet wird, und daher innerhalb der zugehörigen geschweiften Klammern deklariert wird, ist eine lokale Variable. Wird sie allerdings außerhalb der Funktion. bspw. ganz am Anfang des Programms definiert, so ist sie eine globale Variable und behält ihren Wert auch zwischen den Funktionsaufrufen bei.

Also lokal:

——————————-

function()
{
       int x;
       blablatudiestudas;
}

——————————

Und global:

—————————–

int x;
function()
{
       blablatudiestudas;
}

————————–

Wie weiter im Quelltext?

Sehr viel weiter bin ich noch nicht im Buch gekommen und habe damit etwa die Hälfte durchgearbeitet. Die nächsten Kapitel handeln vom Präprozessor, Pointern, Kommandozeilenparametern und davon, wie ich Dateien in C verwende. Die möchte ich gerne noch durchlesen, werde sie aber nicht ganz so gründlich durcharbeiten wie die vorherigen Kapitel. Dann ist es nach anderthalb Monaten Verspätung auch endlich Zeit für Python.

Es mag noch ein wenig verfrüht für ein Resümee sein, aber so richtig zufrieden bin ich nicht mit dem Ergebnis des C-Abschnitts meiner Programmier-Genese. Ich habe das Gefühl, zu wenig gelernt zu haben, um wirklich in C programmieren zu können. In den bisherigen Kapiteln konnte ich die meisten Übungsaufgaben recht schnell lösen. Aber im letzten Kapitel stand ich vor einer Wand, als ich versuchte, mir Programme zu überlegen, mit denen ich die eigentlich relativ leichten Aufgaben lösen könnte. Das war recht frustrierend und führte zu den üblichen Gedanken in Richtung “Ach, Programmieren und ich, naja”. Vielleicht wäre das anders verlaufen, wenn ich enger mit Plom und Erlehmann zusammengearbeitet hätte und ich mehr Fragen gestellt hätte, als mein Unwissen so im Raum stehen zu lassen.

Aber es gibt auch gute Gründe, weswegen Frustration eigentlich abwegig ist.
Zum Einen war das Programmieren in C auch nicht mein erklärtes Ziel. Meine Absicht war es nach wie vor, eher ein Gespür dafür zu bekommen, was C eigentlich ist.  Ich hoffe einfach, dass der nächste Abschnitt Python mir in demselben Maße leichter fallen wird, wie es C nach Assembler tat. Und dass ich nächstes Jahr mehr Zeit habe, um mein C-Wissen zu vertiefen. Aber ein wenig Zeit habe ich ja noch, um das C-Wissen bspw. in einer praktischen Anwendung zu vertiefen und zu überprüfen.

Speaking of “Zeit“. Ein weiterer Grund, weswegen es mir legitim vorkommt, mir die Defizite nachzusehen ist, dass ich in den vier Monaten nicht jeden Tag Programmieren konnte. Zwar hatte ich Semesterferien, aber die Programmier-Lerneinheiten waren immer etwas, was ich zwischen etliche andere Dinge schieben musste. Es war also weniger ein Freie-Zeit-Füllen, als eine Beschäftigung, für die anderen Dingen Zeit entzogen wurde.
Aber diese anderen Dinge waren nicht nur so computerlose Hobbys wie Band und Hausarbeiten, sondern auch die Lektüre von Büchern, die durchaus etwas mit Computer zu tun haben. Neben dem Buch “Theorien des Internets” habe ich auch “Computerphilosophie” begonnen. Und das ist etwas, was ich auch zuletzt bei einem Vortrag in der “Open Tech School” angesprochen und betont habe – das Programmierenlernen hat nicht nur etwas mit dem Aneignen von spezifischer Syntax einer Programmiersprache zu tun. Es eröffnet auch den Zugang zu Themenkomplexen, die vorher wenig naheliegend und unangetastet blieben. Dadurch beschäftige ich mich plötzlich auch mit Netztechnologie, Netztheorie, Konzepten von Berechenbarkeit, Formaler Logik undundund… Dabei bleibt es nicht nur bei der Erkenntnis, dass es doch irgendwie notwendig ist, den ganzen Kram endlich mal zu verstehen, ich interessiere mich auch brennend dafür! Das hätte ich vor einem Jahr, als ich mit meinem Ethnologiestudium vor allem mit meinem Selbstverständnis als Fotografin begann, nicht gedacht…

Speaking of “Uni“. Mir graute es bis vor Kurzem noch ziemlich vor dem Beginn des Semesters. Nicht wenige Tage meiner Semesterferien begannen um 9 Uhr und endeten um Mitternacht, viele Absätze der Lektürenotizen später. Zwischendurch hörte ich Podcasts zur Netzpolitik, las Artikel auf Hacker News, diskutierte mit vielen tollen Menschen über das Programmierenlernen (naja, meistens läuft es doch darauf hinaus, dass ich besoffen den Assembler-Ansatz verteidigen muss) und bereitete Vorträge für ProgrammieranfängerInnen vor. Wie kriege ich das unter bei 22 Seminarstunden plus täglich ca. 4-8 Stunden Lektüre der Texte, Referate, etc.?
Aber der schöne Nebeneffekt des Ganzen ist, dass ich mich zumindest im Uni-Kontext nach und nach zu einer Expertin gemausert habe. Das sagt natürlich auch viel über mein Institut aus, aber es birgt für mich vor allem die Chance, auf das Vertrauen meiner DozentInnen zu setzen und ihre Unterstützung zu erhalten. Die Europäische Ethnologie als Gesellschaftswissenschaft, die sich vor allem mit der Alltagskultur auseinandersetzt, bietet eine Infrastruktur, die mir intellektuelle Grundlagen, Methoden und eine Plattform zur Kommunikation vermittelt, ohne dass ich dabei von meinen eigenen Interessen abrücken müsste. Gerade das Erlernen einer Kulturwissenschaft und die parallele Beschäftigung mit Themen aus der Informationswissenschaft schafft eine Schnittstelle, die m.E. viel zu selten hergestellt wird. Und mit dieser Meinung stehe ich sicher nicht alleine da.
Und es ist auch sicher die Stärke eines kleinen Instituts, wo auch Studierende mit Namen gegrüßt werden, dass ich ein Gespräch mit einem Dozenten führen kann, um mein Projekt, meine Interessen und meine Bedürfnisse an das Studium zu besprechen. Und im Endeffekt Zeit und Punkte für meine Arbeit an FLP aushandeln kann :) Was eine riesengroße Erleichterung ist. Denn es gibt doch einen großen Unterschied zwischen Zeit nehmen müssen oder Zeit haben. Ich werde also die nächsten Monate einen oder zwei Tage die Woche zur Verfügung haben um mich mit dem ganzen Kram zu beschäftigten, theoretisch und praktisch. Insofern werden die nächsten Blogposts öfter Mal abgesehen von Code auch theoretische Überlegungen beinhalten, wenn ein Text sich anbietet, entsprechend kontextualisiert zu werden. Das Buch “Technogene Nähe”, das ich als nächstes lesen werde, wird sicher noch ein paar Mal Erwähnung finden…

Bleibt zu erwähnen, dass heute der Ada-Lovelace-Day ist. Ada Lovelace gilt als die erste Programmiererin bzw. programmierende Person überhaupt. Wenn ihr es bis hier unten geschafft habt, schaut euch mal diese Seite an. Es geht um die Sichtbarkeit von Frauen in den MINT-Bereichen und damit um weibliche Vorbilder, die in Mathematik, Informatik, Naturwissenschaften und Technik tätig waren.
Soweit also der Stand. Coole Sache das Alles. Ich bin selber gespannt darauf, worin die Zusammenführung von Ethnologie und Programmieren fruchten kann. Und wie das wird, wenn ich auf diesem Blog in Zukunft auch mal als Ethnologin schreibe. An Gedanken mangelt es zumindest nicht.

Fun as in Function

Mein Vater sagte zu mir immer: “Funktionier doch mal!”

Das hat mir im Leben nie weitergeholfen, aber ich verstehe jetzt, dass er darauf hinweisen wollte, dass in C viele Funktionen bereits in der Bibliothek vorliegen, aber es gleichzeitig auch die Möglichkeit gibt, selber Funktionen zu schreiben.
Das hatten wir damals auch bei Assembler schon angewandt. Mit “call” konnte eine Funktion, die irgendwo im Code stand, aufgerufen werden.

Wenn eine Funktion geschrieben wird, ist sie genauso aufgebaut wie die “main”-Funktion. Also: Name, Klammern mit Platz für die Parameter, Anweisungsblock in geschweiften Klammern inkl. Deklaration der Variablen. Ein Beispiel:

 #include <stdio.h>

raeum_dein_zimmer_auf () 
{
       int deadline;
       for (deadline=1; deadline<=13; deadline=deadline+1)
              printf("\nIch hab dir jetzt tausendmal gesagt, du sollst
                        dein Zimmer aufräumen!\n");
}

main () 
{ 
....

Und so weiter, und so fort.
Die Variable “deadline” kann ich auch in den anderen Funktionen verwenden, was ich nicht tun würde. Aber für solche häufig verwendeten Variablen wie “x” oder “y” ist das durchaus hilfreich. Der Name der Funktion darf aus Buchstaben, Zahlen und Unterstrichen bestehen und maximal 31 Zeichen lang sein. Der Lesbarkeit und Einheitlichkeit halber sollten Wörter durch Unterstrich getrennt sein, nicht mit einem Unterstrich beginnen und möglichst keine Großbuchstaben beinhalten.

Die Funktion oben ist womöglich gut geeignet, wenn ein gestörtes Kommunikationsverhältnis vorliegt und wenn die Prämisse gilt, dass das Zimmer bis 13 Uhr aufgeräumt sein soll. Aber eigentlich sollten Funktionen flexibler gestaltet werden für andere Anwendungen. Dafür gibt es die Funktionsparameter. Ein Beispiel:

linie(int zeichen, int laenge)
{
        int i;
        for(i=1; i<laenge; i++)                           /*(1)/
                printf("%c", zeichen);
}

main ()
{
        int zeichen, wieoft;
        printf("\nIch schreibe jetzt 10 Fragezeichen.\n");
        linie('?', 10);
        printf("\nWelches Zeichen: ");
        zeichen=getchar();                                
        printf("Wie oft schreiben: ");
        scanf("%i", &wieoft);                             /*(2)/
        printf("\n");
        linie(zeichen, wieoft);                           /*(3)/
        printf("\n");
}

Neu ist zunächst der Ausdruck i++ in der for-Schleife (1). Der bedeutet aber dasselbe wie i+1. Das haben wir bisher verwendet, um dem Programm zu sagen, dass es die Variable um 1 inkrementieren, also erhöhen soll. Sieht anscheinend geiler as in professioneller aus und spart mehr oder weniger wertvolle Lebenszeit.

/*Nachtrag: Falsch, i++ ist nicht dasselbe wie i+1, sondern wie i=i+1,
danke erlehmann! Geht übrigens auch mit i– (dekrementieren)/

Die Parameter in der ersten Zeile sind als int definiert. Die Werte für die Variablen werden in der main-Funktion durch die Eingabe der User bestimmt (2). Bei (3) werden sie als int-Werte an die Funktion übergeben (obwohl eine Zeichenkonstante (char) eingelesen wurde, diese kann aber von C auch als Code des zugehörigen Zeichens interpretiert werden, also für “?” eine “63″).

Ein drittes Beispiel soll die eigentlich wichtigste Funktionen-Funktion darstellen: Die Rückgabe von Werten. Wäre ja schade drum, wenn das Programm für mich 1+1 ausrechnet, ich aber nicht an das Ergebnis komme.

#include <stdio.h>

int max(int a, int b)
{
        if (a > b)
                return a;                     /*(1)/
        else 
                return b;
}

main ()
{
        int zahl1, zahl2, ja1, ja2;
        printf("\nBitte geben Sie eine Zahl ein: ");
        scanf("%i", &zahl1);
         printf("\nBitte geben Sie eine Zahl ein: ");
        scanf("%i", &zahl2);
        printf("\nTrommelwirbel!\n");
        printf("\nBitte irgendeine irrelevante Zahl eingeben: ");
        scanf("%i", &ja1);
        printf("\nWarte... warte... schon aufgeregt?\n");
        printf("\nBitte noch irgendeine Zahl eingeben: ");
        scanf("%i", &ja2);
        printf("\nDie Zahl %i ist groesser!\n",          
                max(zahl1,zahl2));                         /*(2)/
}

Die max-Funktion gibt den größeren von zwei int-Werten aus. Das tut sie aufgrund der return-Anweisung (1). Diese beendet zum Einen die Schleife, zum Anderen sorgt sie dafür, dass der Wert, der ausgegeben wurde an die aufrufende Stelle (2) geliefert wird.
Das passiert in der letzten Zeile dieses Programms, das sich mit schlecht.s um den vorletzten Platz auf dem Sinnvolle-Programme-Ranking streitet. Dem Platzhalter %i wird also der Wert zugewiesen, den return von max aus bekommen hat.

Bleibt zu bemerken, dass man aufpassen sollte, dass die Rückgabetypen der Funktionen rechtzeitig definiert werden. Standardgemäß geht der Compiler davon aus, dass der Rückgabewert vom Typ int ist. Blöd, wenn er nicht int ist, sondern bspw. double. Wenn die Funktion also aufgerufen wird und erst später die nicht-int-Typen definiert werden, ist das Programm im Arsch.  Am Leichtesten lässt sich das natürlich bewerkstelligen, indem die Funktion auf jeden Fall vor dem ersten Aufrufen definiert wird. Das geht ganz einfach, indem man bspw. am Anfang des Programms, noch vor der main-Funktion schreibt:

double func (double, double);

Was irgendwie nach einem generischen Gabba-Song-Titel aussieht, ist ein Funktionsprototyp. In den Klammern müssen keine Variablen-Bezeichnungen stehen, sondern nur die Typen. Außerdem wird die Klammer mit einem Semikolon beendet. Semikolonsemikolonsemikolon. Nicht vergessen!

Hier, nochmal, zum Üben: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

In meinem Chat, den ich hier aus Gründen nochmal ausschreibe:

##fionalerntprogrammieren auf freenode
(join!)

gab es dann heute morgen auch nochmal eine schöne Diskussion darüber, wie sinnvoll die Längenbregrenzung für Funktionsnamen ist.
Eingangs wusste ich einfach nicht, woher die Begrenzung auf 31 Zeichen kommt. Scheint mir “historische Gründe” zu haben. Darauf wurde aber nicht wirklich geantwortet, stattdessen wurde sich darüber gestritten, dass unsinnige Bezeichnungen auch mit weniger als 31 Zeichen möglich sind, Beispiele: ffhvfdhfddchfdvzffbfdf() oder penis2() .
Einige waren der Meinung, dass eindeutige Bezeichnungen auch mal so richtig schön lang sein können und sollten, andere, darunter ich, finden es einfach nur hässlich und unhandlich, wenn Funktionsnamen zu lang sind.

Aber vielleicht hat die Eine oder der Andere noch etwas weltbewegendes dazu zu sagen, dann können wir den Streit in den Kommentaren fortsetzen. Und wer darauf besteht, dass penis(2) eine sinnvolle Bezeichnung ist, wird gelöscht.

I like it double!

Endlich schönes Wetter – die Sonne scheint in mein Zimmer und das stundenlange Programmieren macht gleich viel mehr Spaß!

Nach der Einführung in printf geht Erlenkötter in seinem nächsten Kapitel auf scanf ein. Bisher kann ich ein Programm dazu bringen, mir entweder einen Text oder das Ergebnis einer Rechnung in mein Terminal zu posten. So weit so unnütz. Bzw. umständlich, da ich jeden neuen Term erneut in das Programm hacken müsste. Mit scanf kann ich dynamisch die Werte immer wieder neu eingeben und damit die Variablen mit Werten belegen.

Ein ganz simples Programm wäre z.B.

#include <stdio.h>
main ()
{
1)      int x,y;
        printf("\n\tG e n e r i s c h e s");
        printf("\n\tA d d i t i o n s p r o g r a m m\n");
2)      printf("\nBitte x eingeben: ");
3)      scanf("%i", &x);
        printf("\nBitte y eingeben: ");
        scanf("%i", &y); 
4)      printf("\nDas ergibt eine stolze %i\n", x+y);
        printf("\nMensch, toll!\n\n");
}


Um das Programm auszuprobieren müsst ihr das Programm wie immer in einen Editor packen, compilen und dann ausführen. Es fragt nach zwei Werten, um sie x und y zuzuordnen.

1) X und Y sind in diesem Falle Variablen des Typs Integer. Variablen müssen nämlich immer deklariert werden. Der gemeine Hacker würde jetzt irgendeine verrückte Zahl eingeben und das Programm zum Absturz und meinen Computer zum Explodieren bringen. Der Typ Integer ist zwar sehr leicht verdaulich für einen Rechner, das heißt, er kann damit effizient und schnell rechnen, dafür können die Variablen in diesem Falle nur einen bestimmten Wertebereich abdecken.

2)  Wenn das Programm gestartet wurde fragt es nach einem Wert für x. Den tippe ich ein und scanf 3) liest diesen Wert ein und belegt x damit. Wenn dann auch noch y bestimmt wurde kann das Programm die Rechnung ausführen 4) und gibt das Ergebnis aus.

Und weil ich gestern so fleißig und soziophob war hab ich gleich noch die Programmieraufgabe bewältigt:

Schreiben Sie ein Programm, das den Benzinverbrauch eines Autos in Litern je 100 Kilometern errechnet.

Nix leichter als das, Helmut!

#include <stdio.h>
main () 
{       
1)      float liter, kilometer; 
        printf("\n\t1 B e n z i n v e r b r a u c h\n");
        printf("\nDieses Programm berechnet den durchschnittlichen\n"); 
        printf("Verbrauch von Benzin in Litern pro 100km\n");
        printf("\nBenzinverbrauch in Litern eingeben: ");
2)      scanf("%f", &liter);
        printf("\nGefahrene Kilometer angeben: ");
3)      scanf("%f", &kilometer);
4)      printf("\n\nDer Verbrauch liegt bei %.2f Litern pro Hundert Kilometer\n\n", liter*100/kilometer);
5)      printf("\n\nVielleicht solltest du besser Fahrrad fahren.\n\n");
}


Na zugegeben, der Code leidet ein wenig unter meinen Ästhetikvorstellungen, die sich allerdings auf das ausgegeben Programm im Terminal beziehen.
Bei diesem Programm habe ich die Variablen als float deklariert 1). Float kann einen viel größeren Wertebereich abdecken und Zahlen mit Nachkommastellen darstellen. Isn Ding wa? Wobei der bevorzugte Fließkommatyp double ist, dessen Platzhalter dann nicht mehr %f ist, sondern %lf. Die Genauigkeit bei double erstreckt sich über 15 Nachkommastellen. Wie praktisch!
Das Programm fragt nach dem Start wiederum nach zwei Werten. Einmal nach den getankten Litern 2) und dann nach den gefahrenen Kilometern 3). Die Werte werden dann wieder in der Rechnung eingefügt und das Ergebnis wird ausgegeben.
Allerdings wird das Ergebnis nur mit zwei Nachkommastellen ausgegeben, weil mich der Rest nicht interessiert. (Ich hoffe mein ehemaliger Mathelehrer liest mit und kriegt jetzt das Kotzen hähä!) Die Nachkommastellen kann ich begrenzen, indem ich nicht einfach %f als Platzhalter schreibe sondern %.2f  4)

Ja, haha, mein erstes Programm! Ganz alleine, ohne Schwimmflügel, freihändig, ohne Messer und Gabel, ohne Verstärker, ohne Laktose, ohne HartzIV, nur mit ein bisschen Kreativität und mithilfe von etwa 13 Fehlermeldungen als ich es zum ersten Mal kompilieren wollte…
Aber tatsächlich war das debuggen (das Beheben dieser Fehler) ganz spaßig. Vermutlich weil es größtenteils leicht zu behebende Fehler des Typs “Scheiße, Semikolon schon wieder vergessen” waren. Und natürlich weil es ein recht simples Programm ist. Ich hab’s auch gleich in ‘nen Pastebin gesteckt: http://pastebin.com/70WJMxk7

Ja, ach, was bin ich stolz mich betrinken gegangen danach.

Wenn ihr jetzt ein Benzinverbrauchsprogramm braucht, könnt ihr gerne meins benutzen, ihr müsst auch nix bezahlen oder so, gnihihihi…Vielleicht habt ihr ja Linux auf eurem Auto, dann könnt ihr das gleich anwenden. Aber nicht dass ihr das falsch versteht: 5)

Überhaupt möchte ich als nächstes lieber ein Programm für Fahrradfahrer_innen schreiben. Vielleicht eines, das Zwischenwerte von Kalorien- oder Wasserverbrauch pro km zwischenspeichert in einer Datei. Aber das muss ich erst noch lernen. Außerdem wurde mein Hinterrad geklaut und ich gönne es natürlich Nichts und Niemandem auf der Welt gerade, Fahrrad fahren zu können. Bis ich wieder das Geld habe um mein Fahrrad zu reparieren. Bis dahin dürfte aber noch *hust ein wenig Zeit vergehen…

———————————

Achja, vermutlich hagelt es in den Kommentaren jetzt Facepalms und Verbesserungsvorschläge oder beides gleichzeitig. Aber bedenkt bei euren äh…Ratschlägen bitte, dass ich das Programm mit meinem vorhandenem Wissen geschrieben habe. Also nehmt nicht zu viel vorweg, besserer Code wird folgen, sobald ich mehr gelernt habe. Aber für hilfreiche Tips bin ich natürlich dankbar :)

Getaggt mit

I C & U

Lang ist’s her, Freunde und Freundinnen und Bernd!
Aber manchmal müssen die Dinge auch einfach ruhen. Damit zum Beispiel der Shitstorm vorüberzieht und ich über Tech-Themen schreiben kann ohne mein mittlerweile >9000 Stimmen großes Gewissen im Hinterkopf. Oder bis ich die Scherben meiner Uni-Prokrastination. So kurz vor Scheinausgabe.

Jedenfalls freue ich mich jetzt auf viel Zeit zum Programmieren, basteln, bausteln und bloggern! Bis ich dann in zweieinhalb Monaten feststelle, dass ich noch die Hausarbeit in Kulturtheorien NAEGAL

Um an den vorherigen Post anzuknüpfen – ich hab ja das Buch gewechselt, von Kernighan&Ritchie zu Erlenkötter. Was sich nach einer ziemlichen Einbuße an Coolness anhört ist ein wichtiger Schritt nach vorn für mich gewesen. In den Kommentaren des letzten Posts ist übrigens gut nachzulesen, weswegen manche K&R für den überlegenen Weg halten, aber es bewährte sich trotzdessen meine These, dass es nicht für komplette Programmier-Neulinge wie mich geschaffen ist. Und mit Neuling meine ich, dass ich noch nicht sehr viel Praxis habe, vor allem auf dieser Abstraktionsebene.

Fangen wir also mit dem guten, alten, konservativen, erzkatholischen Vorne an. Was ist C?

C ist eine Programmiersprache. Und sie heißt C, weil sie auf die Sprache B folgte. Genau genommen auf die Sprache BCPL, oder auch “Before C Programming Language”. Rekursion und so, haha. Sie wurde in den Siebzigern in den Bell Laboratories entwickelt, um auf Unix zu programmieren und um eine Assembler-Situation zu vermeiden. Von den mittlerweile bekannten Antagonisten Kernighan und Ritchie wurde sie veröffentlicht. Ende der Achtziger wurde sie von einem ANSI-Kommitee standardisiert und bis heute mehrmals weiterentwickelt. Unter anderem zu Objective C und C++, woraus sich wiederum Java entwickelte.

Und was bringt mir C nun? Na ich kann damit Programme schreiben! Zum Beispiel so geile Rechenprogramme oder Spiele oder sogar Blogs. Dafür schreibe ich erst einen Quellcode, dann kompiliere ich den und dann linke ich das Ganze. Kompilieren bedeutet, dass ich ihn von einer Sprache in die andere übersetze, z.B. von C nach Assembler. Und das ist ne feine Sache, so ein Compiler. Aber darüber schrieb ich schon vor langer Zeit – trotzdem, ich kriege immer noch ein bisschen feuchte Augen wenn ich dran denke, wie schön und magisch und genial… usw.
Der Linker verbindet den Programmcode mit den Bibliotheken, die gebraucht werden. Er ist sozusagen die studentische Hilfskraft, der vom Code (dem Prof) in einer schlecht formulierten Email gesagt wird “Heyhey, ja, die Stabi, und die Regwibi und die stdio, da brauch ich überall Kopien von Dings für das Paper!” Und der Linker muss dann schauen, welche Funktionen gebraucht werden und in welcher Bibliothek sie lagern. Eine Funktion kann bspw. “printf” sein und die findet man in der stdio-Bibliothek. Diese bindet der Linker dann mit dem Programm. Und statt der bloßen Anweisung “print” steckt dahinter eine Funktion, die sich gewaschen hat!

Und jetzt? H4ck0rn! Zum Anfang ein kleines Rechenprogramm. Ich nenne es “kleines Rechenprogramm”. Es gibt Text und eine Rechenaufgabe in mein Terminal aus und berechnet gleich noch die Lösung, als hätte es nie was Anderes getan!

#include <stdio.h> 
main () {
        printf("\nDies wird dein Leben verändern\n");
        printf("13 * 7 = %i \n", 13 * 7 );
        printf("\nMagie!\n") ;
        }

In der ersten Zeile wird angegeben, welche Bibliothek inkludiert werden soll. In diesem Falle die Standard-Input-Output-Bibliothek.
Main bedeutet soviel wie “Hauptfunktion jetze”, wobei in den Klammern die hier leer sind für gewöhnlich Parameter angegeben werden. Die geschweiften Klammern umrahmen einen Block von Anweisungen, in diesem Falle drei printf-Funktionen.

Jeder printf-Anweisung folgt ein Text in Klammern und Anführungszeichen, der ausgegeben werden soll. Die \n-Dinger sind Escapesequenzen und bedeuten “new line”, es wird also eine neue Zeile angefangen. Escapesequenzen werden immer mit einem Backslash geschrieben.

Ach und ganz wichtig: Nach jeder dieser Klammern ein verficktes Semikolon. Nicht das verdammte Semikolon vergessen, nein, nicht vergessen!

Soweit, so nachvollziehbar. Aber behold! Die Zeile mit den Zahlen sieht schon ein bisschen komplizierter aus, stimmt’s? Ist aber eigentlich sehr schlüssig aufgebaut. In den Anführungszeichen steht die Aufgabe, die geprinted werden soll. Aber statt des hässlichen %i wird das Ergebnis des Terms nach dem Komma dafür eingesetzt. Das rechnet printf ebenfalls aus.

Und das Semikolon nicht vergessen und nicht die zweite geschweifte Klammer vergessen! Fertig ist das Programm.
Jetzt verwandeln wir das Programm kleinesrechenprogramm.c in ein Programm namens kleinesrechenprogramm mithilfe eines Compilers

cc kleinesrechenprogramm.c -o kleinesrechenprogramm

um es dann auszuführen:

./kleinesrechenprogramm

Und dann steht Folgendes in meinem Terminal:

Dies wird dein Leben verändern

13 * 7 = 91 
Magie!

Ist das nicht geil??? Jetzt könnt ihr immer, wenn keiner danach gefragt hat, Rechenaufgaben nicht nur lösen, sondern auch schön ausschreiben. Im Supermarkt, in der Uni, auf Partys, zu Hause, alleine…

Ich habe jetzt erstmal versucht, das Programm ein bisschen umzumodellieren, um es aus dem Kopf schreiben zu können. Weitere Rechenoperationen sind +, -, und / für Division. Das klappt auch schon ganz gut, spätestens nach diesem doch hoffentlich idiotensicheren Post. Viel Spaß beim Nachprogrammieren, aufstrebende Nachwuchshacker. Ich weiß es ist ein kleiner Schritt, aber was dich am Trinken im Park hindert, macht dich nur blasser.

Gute Nacht!

Getaggt mit

C für Dummies

Mit dem guten Gewissen, dass ich gerade jede Menge Trollfutter produziere, lege ich mal trotzdem offen, dass wir gerade so etwas wie eine Krise hatten bei FLP. Mal wieder. Daher auch der etwas lange Abstand zwischen diesem und dem vorherigen Post.

Der Anfang von unserem C-Abschnitt des Jahresplans begann zwar holprig aber ich hatte schon nach der zweiten Session das Gefühl, dass unser Konzept, mit etwas absurd Schwerem anzufangen, damit alles danach umso leichter erscheint, aufgeht. Das Gefühl hielt etwa eine Woche an und verschwand vor der vierten Session komplett.

Die ersten Programme erschienen mir noch relativ eingängig und ich war überrascht, wie lesbar der Code im Vergleich zu Assembler-Programmen ist. Aber die Konzepte, die ich nach einem geschriebenen oder optimierten Programm verstanden hatte waren nicht so tief verankert, wie es nötig gewesen wäre um das Buch stringent durchzuarbeiten. Die nächste Session war entsprechend zäh und anstrengend, weil die Konzepte in einer komplexeren Form angewandt wurden, ohne dass ich die simpleren Anwendungen verinnerlicht hatte. Das frustrierte ganz schön und machte das Programmieren langwierig, anstrengend und spaßfrei. Vor der letzten Session wurde mir klar, dass die Lust aufs Programmieren völlig verflogen war. Ich wusste gar nicht mehr so richtig, wieso ich das noch mache und dachte, ich könnte jetzt genauso gut auch aufgeben und würde nicht wirklich drum trauern.

Aber das war für mich kein Grund aufzuhören, sondern ein Signal dafür, dass sich etwas ändern musste. Also sprach ich Plom darauf an und teilte meine Sorgen so offen wie nur möglich mit. Ich glaube ich konnte das Problem darauf runterbrechen, dass ich mich unter Druck gesetzt fühlte. Irgendwie war das Ziel, Programmieren zu lernen dem Ziel, das Buch durchzuarbeiten gewichen. Zur Erklärung vielleicht einfach das Chatlog vom 12.Juni:

18:54 <Fotografiona> ich steh gerade vor dem ziemlich großen Problem, dass ich absolut keine Lust aufs Programmieren habe, weil ich bis jetzt an einer Unisache verzweifelt bin. Und irgendwie den ganzen Tag nur gestresst war. Und jetzt müsste ich zum Programmieren. Was ich aber immer weniger als eine schöne Sache sondern immer mehr als eine
18:54 <Fotografiona> ziemliche Herausforderung empfinde
18:55 <Fotografiona> unter Anderem weil wir einen Zeitplan haben
18:55 <Fotografiona> ich weiß selbst nicht genau was jetzt das beste wäre
18:55 <Fotografiona> einfach trotzdem zum Programmieren treffen?
18:55 <Fotografiona> hoffen, dass es gut läuft? kurze pause?
18:56 <Fotografiona> aber irgendwas läuft schief. irgendwie
18:56 <Fotografiona> vielleicht auch nur bei mir
18:57 <Fotografiona> ich hab seit Sonntag so viel drüber nachgedacht
18:58 <Fotografiona> und ich merke, dass es immer weniger das ist, was ich mir darunter vorgestellt habe. Oder dass es immer weniger in mein leben passt. Wie rum weiß ich nicht. Aber ich wünschte, manchmal, wir würden uns zum Programmierenlernen treffen und nicht zum Buch-schaffen
18:58 <Fotografiona> es ist einfach zu viel
18:58 <Fotografiona> es brauchte nur zwei Sitzungen bis ich wieder das Gefühl hatte, den Faden zu verlieren
18:59 <Fotografiona> Und ich glaube ich hab nur zugestimmt, sich so schnell wieder zu treffen, um dich zufriedenzustellen oder zu beruhigen
19:05 <plomlompom> Oh! Verstehe.
19:05 <plomlompom> Na was hältst du davon, wenn wir den Rest der vier Monate “C” einfach ohne das Buch machen?
19:06 <plomlompom> Hab zwar keinen Plan, was wir dann genau machen sollten in der Zeit, aber wir können ja auch einfach improvisieren.
19:06 <Fotografiona> puh. klingt nach ner guten Idee
19:06 <plomlompom> Denn das “zum Programmierenlernen treffen und nicht zum Buch-schaffen” klingt nach einem sehr guten Punkt.
19:07 <Fotografiona> ist ja an sich vielleicht gar nicht dumm, die Programme aus dem Buch zu nehmen. aber vielleicht verstehe ich mehr, wenn du es mir einfach erklärst
19:07 <plomlompom> Wollen wir uns trotzdem heute treffen?
19:08 <plomlompom> Dann können wir ja statt Übungen machen einfach überlegen was wir die restlichen zweieinhalb Monate “C” machen ;)
19:08 <Fotografiona> ich bin ziemlich im eimer und abgenagt. ich hab einfach angst, dass es blöd werden könnte
19:08 <Fotografiona> und reizbar bin ich leider auch :/ wie du vielleicht schon gemerkt hast ;)
19:08 <plomlompom> Ach naja wir können einfach entspannt beisammen sitzen und mit erlehmann rum-improvisieren, ohne Druck.

So weit die Vorbesprechung. Lustigerweise änderte sich an dem Abend absolut gar nichts. Wir programmierten wieder fast zweieinhalb Stunden am Stück an einem Programm aus dem Buch rum, lasen den Text dazu und ich verstand so gut wie gar nichts. Also naja, ich verstand schon die Funktionsweise aber konnte nicht vorausschauend das Programm beschreiben und auch nicht alle Details der Funktionsweise verinnerlichen und abrufen. Plom gab sich durchaus Mühe dabei, mir das Programm nahezubringen und erlehmann redete einen Tick mehr topic-related dazwischen als sonst. Zum Einen war ich aber etwas abgelenkt von einem bunten Menschen-Auflauf aus KünstlerInnen mit Trompeten und Nerds in Feuerwehranzügen, zum Anderen war ich wie im Chatlog beschrieben schon total ausgebrannt, bevor ich dort ankam. Und darüber hinaus hatte ich mich kein Stück auf den Abschnitt aus dem Buch vorbereitet. Meine Augenringe hängten gefühlt bis zum Boden und danach war ich nur noch viel frustrierter und erschöpfter.  Wenn diese Session etwas gebracht hat, dann die Erkenntis, dass wir dringend etwas ändern mussten.

Wir sprachen auch darüber, als ich schon mit dem Kopf auf der Tischkante lag. Wie können wir die zukünftigen Sessions gestalten? Wir wollten auf jeden Fall das Buch kicken. Unsere Technik, dass ich einfach das Buch vorlese und wir nach jedem Abschnitt Fragen klären klingt zwar plausibel aber war so dröge wie ineffektiv (und anstrengend!) Darüber hinaus ist das Buch von Kernighan und Ritchie einfach nicht für AnfängerInnen gedacht. Es scheint eher für Leute zu sein, die entweder den Vorgänger B oder Fortran oder *hust* Assembler oder Anderes beherrschen. Ich hätte, um dabeizubleiben immer wieder das Erlernte wiederholen müssen, damit die Session effizient und lehrreich waren. Ich hätte mich auch vorbereiten sollen, damit wir nicht immer nur 5 Seiten in drei Stunden schaffen. Aber zum Wiederholen fehlt mir momentan einfach die Zeit. Zwischen Unitexten am Fließband, Seminaren, Musik, Herzmschmerz, Forschung, wenig Schlaf und Freunden blieb bisher wenig Platz und Nerv dafür, sich nochmal ein paar Stunden mit dem Buch und den Programmen auseinanderzusetzen. Aber darin lag wohl auch das weitere Problem – ich konnte das Buch eh nicht alleine bearbeiten. Dafür ist es einfach nicht Anfänger-freundlich genug. Der einzige Lernfortschritt musste also in den Sessions stattfinden und das mit teilweise zwei Wochen Abstand.

Das klingt jetzt alles so furchtbar, wie ich es aus Mitleidsgründen beabsichtigt habe. Aber nicht zu vergessen bleibt, dass wir nicht ohne Grund eine kleine Lerngruppe haben und dafür werben, es uns gleichzutun. Denn ich muss jetzt nicht anfangen, das Assembler-Seminar zu schwänzen, mich nicht darauf einstellen, den Kurs nächstes Jahr nocheinmal zu besuchen und mich auch nicht hinterklemmen, und tagein tagaus versuchen, wieder aufzuschließen, um doch nen Schein abzugreifen und in der Regelstudienzeit zu bleiben. Denn dank unseres überlegenen Lernkonzeptes sind wir ja flexibel! \o/

Also haben wir beschlossen, in Zukunft nicht mehr mit dem Buch “C” zu arbeiten. Denkbar ist es, weiterhin Struktur und evtl. Beispielprogramme zu übernehmen, aber in einer anderen Geschwindigkeit und mit mehr Zwischenstufen. Vielleicht auch mal mehr eigene Programmierideen umsetzen. Weniger Zeitdruck. Und überhaupt. Ich glaube ich sollte mich mal wieder in der Uni blicken lassen.

Das letzte Mal als ich da war, hab ich z.B. auch endlich das für mich hinterlegte Buch  “C Programmieren von Anfang an” abholen können das mir ein Freund leihte, der die Leidenschaft für’s Schädelvermessen mit mir teilt. Das war gestern und es hat mich über ein vierstündiges Kulturtheorien-Seminar gerettet! Es ist tatsächlich ein sehr hilfreiches, gut geschriebenes Buch, mit vielen Erklärungen, für AnfängerInnen, mit ganz ganz kleinen Schritten. Das erste Programm wird Schritt für Schritt erklärt, das nächste hat nur ein paar kleine Zusätze u.s.w. Ich kann es nur empfehlen, für alle, die mit C anfangen wollen.
Ich weiß ehrlich gesagt nicht, weswegen alle einem das Buch von Kernighan und Ritchie ans Herz legen. Weil es so… authentisch ist? Immerhin haben die Beiden C erfunden. Aber im Gegensatz zu dem neuen Buch war “C” weitgehend wertlos.

Jetzt freue ich mich jedenfalls wieder aufs Programmieren und bin sehr zuversichtlich. Ich habe auch plötzlich Lust, die 20 Seiten die ich in 10 Minuten Ubahnfahren durchgelesen hab so bald wie möglich nachzuprogrammieren. Und extra ein paar Stunden meines Tages dafür zu investieren. Ich bin wieder neugierig und zuversichtlich und der so fatale wie ausdauernde Gedanke, es hätte was mit mir und irgendwelchen grundlegenden, unveränderlichen Charaktereigenschaften (zu dum) zu tun, dass ich keine nennenswerten Fortschritte mehr gemacht habe, ist wie verflogen.

Um meine (und unsere) aus dem Scheitern gewonnenen Erkenntnisse mal kompakt zu formulieren:

Es ist definitiv von Vorteil, das Lernformat flexibel zu gestalten.
Es hilft nichts, sich oder anderen zu hohe Lernziele zu stecken. Dabei geht nur der Blick dafür verloren, was man tatsächlich für Fortschritte macht.
Anfänger werden Anfängern.
Probleme beim Lernen sollten sofort angesprochen werden, damit zeitnah Lösungen gefunden und Frustrationen auf beiden Seiten vermieden werden.
Das C-Buch ist kacke. Das Neue ist cool.

Und noch eine Sache. Dass ich diesen Artikel verfasst habe ist auch ein wenig befreiend für mich. Wenn ich offen damit umgehe, dass mir das Programmierenlernen nicht ganz so leicht fällt heißt das für mich persönlich auch, es zu akzeptieren. Und für die LeserInnen womöglich auch. Manchmal habe ich den Verdacht, dass ein falscher Eindruck in diesem Internet von mir kursiert. Mir fällt das mit dem Programmierenlernen wirklich verdammt schwer. Ich kann ne Menge Dinge. Ich kann wenige Dinge gut und nichts wirklich richtig gut. Außer Tofu braten vielleicht.

Mir fällt das Programmieren nicht zu. Keineswegs. Es ist anstrengend, immer wieder eine ziemliche Herausforderung und schwierig. Klar, ich hab mit Assembler angefangen. Aber ich bin keine Assemblerprogrammiererin. Ich weiß, was Assembler ist und kann kompilierten Code einigermaßen nachvollziehen. Ich wende es aber nicht an und ich verstehe fremden Assemblercode nicht ohne Weiteres. Ich habe dafür ne Menge über Computerarchitektur und -funktionsweise gelernt. Das heißt aber nicht, dass ich alles verstanden habe, was mir beigebracht wurde. Ich habe auch oft Konzepte verstanden, könnte sie aber vermutlich nicht korrekt und ohne Verwechslungen wiedergeben.
Klingt komisch, ist aber so. Und völlig in Ordnung. Ich habe von Januar bis April mehr gelernt bei FLP als ich ohne FLP gelernt hätte. So einfach ist das.
Aber mir ist zuletzt bei der Sigint, wo wir ein wenig über unsere Vorgehensweise und Motivation sprachen, aufgefallen, dass sich das Bild, das wahrgenommen wird und wie es tatsächlich läuft nicht ganz entsprechen. Bei dem Vortrag schien ich mehrere Menschen damit zu irritieren, dass ich immer wieder auf meine Unfähigkeiten hinwies. Ich glaube, sie haben einfach etwas Anderes erwartet. Und das hat mich sehr nachdenklich gemacht.
Ich will keinesfalls den Eindruck erwecken, dass mir das alles leicht fällt. Das wäre die falsche Botschaft und würde nicht stimmen. Wenn ich in diesem Blog zum Programmierenlernen motivieren möchte, ist es nicht zielführend wenn ich vorgebe, das wäre eine einfache Angelegenheit. Das kann es für manche sein, für mich gilt das nicht. Ich habe andere Stärken. Ein Musikinstrument lerne ich im Nullkommanichts. Eine neue Programmiersprache – das dauert.
Ich will keinesfalls Leute vom Programmieren abschrecken. Und auch wenn es vielleicht so wirkte, empfinde ich mich ja keinesfalls als scheiternd. Denn meine eigentliche Leistung ist für mich total offensichtlich – War sie aber nicht für das Publikum: Ich habe durchgehalten! Ich habe nicht den Mut verloren und beiße mich eben dadurch. Ich finde das gerade weil es so schwer ist gar nicht mal so übel.

Und so wie es mir zuletzt mit C ging wäre ein Aufgeben verdammt naheliegend gewesen. Aber ich möchte weitermachen und mich lieber mit dem Lernprogramm auseinandersetzen als aufzuhören. Die Motivation ist ja – spätestens jetzt – wieder da. Nicht zuletzt, weil das Blog auch oder vor allem dazu dienen soll Andere zum Programmierenlernen zu ermutigen. Und jetzt freu ich mich wie ein junges Reh auf die Arbeit mit dem neuen C-Buch!
(Und das trotz vier Stunden Schlaf, Rückenschmerzen, Konzert heute Abend und Semesterendspurt ;)

Getaggt mit
Follow

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 99 Followern an