ubuntuusers.de

Also ich finde, man sollte schon mal ein grundlegendes Buch in die Breite der Thematik Linux durchackern. Das kann gerne 500 Seiten dick sein. Wie dick wäre denn Galileo? Die Gliederung war ja nicht schlecht. 😉 Evtl. kann man ja vertiefende Informationen erstmal einfach überspringen, ebenso das Aufsetzen eines Webservers und dergleichen.

Es ist wie überall im Leben: Einmal ein gutes Buch lesen ist durch nichts zu ersetzen (außer durch sehr viel Stochern in Google, was ich auch gerne tue).

Das trifft doch auch auf jede grundlegende Vorlesung zu (ein Buch), nicht wahr? 😉 Erst dann bekommst du ein Gefühl dafür, welche Kapitel du vertiefen kannst, durch Spezialbücher und spezielle Tutorials.

Edit: Es hat 1120 Seiten. Ich würde es dir trotzdem oder gerade deswegen empfehlen. 😉 Probiere manches am besten gleich aus, sonst versteht man es schlecht, falsch oder merkt es sich nicht - jedenfalls mußte ich damals sehr viel nachdenken, besser wäre ausprobieren gewesen. Außer, man hat die Geduld und die kognitiven Kapazitäten, viel nachzudenken, und die Praxis erst später folgen zu lassen. Ohnehin muß man erst einmal die Grundlagen lesen, bevor man einfach drauf lostippt.

@Lunar:

Deine Einwände sind durchaus richtig. Man kann ohne Vorwissen keine komplexen Probleme lösen. Es wäre ja auch keine große Sache, mal schnell C zu lernen, so groß ist der Befehlssatz nicht. Mein Vorschlag beruhte auch auf Unwissenheit: Ich weiß nicht, ob sum irgendwelche Vorkenntis hat, er bezeichnet sich selbst als relativ neu in der Gegend, da würde es Sinn machen, sich erst einmal intensiver mit dem Betriebssystem auseinander zu setzen.

Mir fehlen jetzt zwei Dinge: Erstens eine klare Beweisführung, die darlegt, warum mein Vorschlag zu vermeiden ist (weil es aus a,b und c schädlich ist), und zweitens ein konstruktiver Ansatz für den Fragestellenden. Ich glaube nicht, dass er viel davon haben wird, einer Diskussion zu folgen, geführt von zwei, die den Scheiß studiert haben (hast du doch, oder?).

Ich sehe das laufend bei Schülern: Die einen geben nach ein paar Tagen auf, weil sie nicht verstehen, warum sie Zahlen in Arrays sortieren sollen, die anderen kommen zwar subjektiv langsamer voran, bleiben aber am Ball, weil sie mit jeder geschriebenen Zeile Code auch ein Erfolgserlebnis haben. Ich weiß aus eigener Erfahrung, dass theoretische Autodidaktik funktionieren kann, würde sie aber keinem empfehlen, weil die Erfolgschancen geringer sind, basierend auf Neigung einzelner (pädagogische Vertretbarkeit). Wenn du weiter über Lehr-/Lern-Didaktik quatschen möchtest, schreib mir eine PM.

Ich hab da noch das Argument gelesen, BASH sei schnell ausgeschöpft. Ja, umso besser, dann hat man schon nach einer Woche den von mir gewünschten Effekt anstatt nach einem Monat, nämlich eine Vorstellung von dem, was man da eigentlich tut. Dass BASH relativ witzlos ist, ist mir klar, es soll ja auch nicht lehren, wie man programmiert, sondern was Automatisierung ist.

Die schöne Grundsatzdiskussion... Theoretiker vs. Kaltwasserspringer. Eine der ältesten in der Geisteswissenschaft überhaupt. ^^

Hi Simon,

willkommen auf dem Forum !

Das wichtigste hat Awebb oben schon gesagt, dem kann ich mich nur anschließen.

Die ideale Kombination zwischen Programmieren und System erkunden ist einfach bash .
Das "spielt" auf der Grundmaschine (also nicht in erster Linie den Anwendungen) und ist einigermaßen überschaubar.
- Sollte also Deiner Zielvorstellung nahe kommen. Ist natürlich ziemlich "wurzelnah". Aber das hast Du ja gewollt.

Vielleicht gebe ich Dir einfach mal meine eigene Linksammlung. Erschrick nicht, sie ist zum Großteil englisch.
(macht Dir das was aus ? - die Befehle stammen sowieso aus dem Englischen...)

- Als Vorwort vielleicht aus dem örtlichen Wiki hier: http://wiki.ubuntuusers.de/Shell/Bash-Skripting-Guide_f%C3%BCr_Anf%C3%A4nger

- Für den Einstieg: http://www.ibm.com/developerworks/library/l-bash.html
(mit den Beispielen kannst Du schön probieren und spielen)

- Befehlsübersicht für bash : http://ss64.com/bash/

- Die man-pages: http://linux.die.net/man/
(Sowieso ist der Befehl man absolut der wichtigste um sich schlau zu machen: alles über Befehle und Programme,
  und hier findest Du auch noch viele gute Hintergrundinfos dazu.)

- Das bash-Handbuch: http://www.gnu.org/software/bash/manual/bashref.html
(da steht nun alles drin, aber da schaut man meist nur im letzten Zweifel nach)

Ansonsten: probiers einfach, beiss Dich durch. Dafür wünsche ich Dir die nötige Geduld und Ausdauer !
Success !

LG,

track

Hm, ich würde Programmierung irgendwie nicht mit Bash gleichsetzen. Aber jedem das Seine.

Da du von grundlegendem Verständnis gesprochen hast:

Ein wirklich gutes Buch: http://www.amazon.de/Algorithmen-Datenstrukturen-Niklaus-Wirth/dp/3519022508

@Benno-007

Meine Grundvorlesung ( ❗ 30 Jahre her ) mit gleichem Titel hätte ich uneingeschränkt empfehlen können. 😇

In der ertsen Vorlesung fingen wir an mit:

Gegeben: Ein Vorlesungssaal mit über 250 Studenten
Gesucht: Der jüngste Kommilitone

Im Dialog mit dem Prof haben wir den folgenden Algorithmus entwickelt und an die Tafel geschrieben:

Beginne in der ersten Reihe rechst vom Prof aus gesehen.
Stehe auf und sage deinen Geburtstag
Solange die letzte Reihe rechts nicht erreicht ist:
Gehe eins nach links, wenn links keiner mehr ist, gehe eine Reihe noch hinten ganz nach rechts
Stehe auf und sage deinen Geburtstag, wenn du jünger bist als der, der gerade steht

Ergebnis:Der am Ende des Programms steht ist der jüngste.

Bevor wir das "Programm" gestartet haben, sollten wir raten, wie oft jemand aufstehen muss. Wir einigten uns auf ca. 50, tatsächlich waren es dann 6. In der zweiten Stunde haben wir in einer Aufwandsabschätzung (wird das heute noch gelehrt?) gezeigt, dass das Ergebnis 6 sehr viel wahrscheinlicher war, als die von uns Anfängern (an einen PC zu Hause war damals noch nicht zu denken) geschätzten 50.

Dann haben wir uns darüber unterhalten, was man tun muss, um das ganze einer Maschine beizubringen. Z.B. bezüglich der Sprache: Worher soll eine Maschine wissen, dass Student und Kommilitone das gleiche bedeuten? oder bezüglich der Eingabe: Wie bekomme ich über 250 Studenten in einen Computer? und falls ich das schaffe: Wie steht ein Student im Computer auf? usw.

So kamen wir zum Abstraktionsprozess.

Ich fand das beeindruckend, wie man sieht, denn ich weiß es noch bis heute.

@Awebb: Ich würde ja sagen, dass man erstmal eine gewisse theoretische Grundlage braucht, um überhaupt den Weg zum Wasser zu finden … reinspringen kann man dann immer noch, aber es ist eben leichter, wenn man weiß wo ☺ Spätestens beim ersten eigenen Programm springt man so oder so ins kalte Wasser, aber es fällt halt leichter, wenn man zumindest theoretisch weiß, was man tut. Es geht ja nicht um theoretisches Wissen zu Datenstrukturen, Algorithmen, usw., sondern um die grundlegenden Werkzeuge (e.g. Schleifen, Funktionen, Objektorientierung, usw.).

Ein Anfänger wird auch nicht durch ein paar einfache Bash-Übungen beizeiten eine echte Vorstellung vom Programmieren bekommen, geschweige denn, Programmieren lernen. Bash führt ja auch nicht weiter … nach ein paar Automatisierungsaufgaben ist Schluss, weil die Sprache nicht mehr hergibt. Wenn man Programmieren lernen möchte, dann auch mit einer vernünftigen Programmiersprache, und keiner beschränkten Skript-Sprache ohne echte Typen, ohne Datenstrukturen und mit allerlei merkwürdigen Quoting- und Erweiterungs-Regeln.

@schusch: Ja, Aufwandseinschätzungen werden heute noch gelehrt.

@Lunar Immerhin passiert jetzt was in dem Thread 😀

Kniggemeier schrieb:

Hm, ich würde Programmierung irgendwie nicht mit Bash gleichsetzen. Aber jedem das Seine.

Ich würde eine ein-Satz-lange, unbegründete Meinung auch nicht als Beitrag ansehen, aber das handhaben andere wohl anders.

Mhm,

@schush - Bei mir in der Vorlesung damals ging es nicht ganz so. Erstmal Syntax (theoretische Grundlagen) etc.. Dann Datenstrukturen u. Algorithmen etc.. Wahrscheinlich ist es doch besser erstmal ein bissl "Theorie" zu können um überhaupt mal sinnvolle Algorithmen verstehen und anwenden zu können. ☹

Gruß, Sven.

@AwebbIns kalte Wasser springen beim Programmieren, erfordert nahezu ständige Kritik von anderen, sonst erreicht man nichts oder produziert nur mehr oder weniger funktionierenden Code in schlechter Qualität. Kritik von anderen bekommt man aber nur wenn man sich als interessant und mehr oder weniger würdig erweist, also kommt man sowieso nicht drum herum Grundlagen erstmal so zu lernen.

Hmm, das kommt jetzt zwar ein bisschen "wenn Halbblinde Blinde führen 😉"-mässig wenn Tipps von einem kommen, der vor einem Jahr genau an einer ähnlichen Stelle wie du stand [Fachfremdes Studium - einfach Bock Programmieren (wiederzuer)lernen (hatte etwas mit Locomotive BASIC auf nem Schneider CPC als Kind rumgespielt) - autodidaktischer Ansatz (liegt mir) - und durchwühlen (Threads hier im Forum mit den Diskussionen welches die beste Anfängerprogrammiersprache ist, Google-Ergebnisse, usw.) bis kurz vor der Verzweiflung] aber wir haben ja hier genügend Mitleser, die ja zum Teil sogar "den Scheiß studieren/studiert haben" 😉, die mich korrigieren werden. So hab' ich ja vielleicht auch was davon?!

Mein (Haupt-)Faden (natürlich hatte ich auch immer wieder andere Dinge ausprobiert, die mir persönlich aber nicht zugesagt haben - zum Beispiel die hier vorgestellte BASH *duck* 😉) sah im Nachhinein betrachtet so aus:

Hier hab' ich mir die ganze Vorlesung angeschaut. Der Ansatz der Dozenten über eine vom MIT, einer der weltweit führenden Hochschulen im Bereich Forschung und Lehre, ursprünglich zum Programmieren lernen entwickelte (- ja ich weiß: ältere und in der Wirtschaft wenig verbreitete) Programmiersprache Scheme und das ebenfalls von dort stammende Konzept, mit Hilfe von sogenannten Konstruktionsanleitungen (Schablonen) zu arbeiten, ließ mich fast voll und ganz auf die Abstraktion und schrittweise Verfeinerung bis zur Lösung des Problems konzentrieren, erst mal ohne mich (viel) um die Syntax der Programmiersprache zu kümmern. Das begleitende Buch hat mir dann auch viel Spaß gemacht und beim Vertiefen geholfen (z.B. die Übungsaufgaben). Ein Tip, wenn dir das ganze an sich zusagt - aber du nicht soo viel Lust auf die Mathematik dahinter hast (mir persönlich hat es Spaß gemacht): Laut eigenen Aussagen der Dozenten ist ihr Ansatz so konzipiert, dass man auch ohne die hier von den Vorpostern verpöhnten mathematischen Grundlagen (vor allem Induktion (als Grundlage zur Rekursion) und das Lambda-Kalkül (als Vorlage zum grundlegenden Aufbau der Programmiersprache) das Buch (und somit die Vorlesung) durcharbeiten kann. Mehr dazu steht im Vorwort des Buches. Dieser erste Teil der Vorlesung arbeitet vom Programmierstil her übrigens funktional.

Dann habe ich den zweiten Teil der Vorlesung angefangen bei der mit der Programmiersprache Java auf einen objektorientierten (Programmierstil-)Ansatz gewechselt werden sollte, was mir an sich sehr gefallen hat. Ich bin aber leider ehrlich gesagt mit der Java-Syntax nicht so warm geworden (*nochmal duck* 😉) und wurde auf meinen "Ausflügen" im WWW während meines Selbststudiums schon vorher öfters mal von der Programmiersprache Python "angefixt" und hier bin ich seit dem bei folgenden Büchern geblieben:

Objektorientierte Programmierung mit Python 3. Einstieg, Praxis, professionelle Anwendung habe ich durchgearbeitet und vertiefe gerade mit Das Python-Praxisbuch: Der große Profi-Leitfaden für Programmierer, welches sich an den Fortgeschrittenen richtet, mein Wissen etwas.

Zum Anwenden des Gelernten witzig hätte ich auch viel früher entdecken sollen: Der Algorithmus der Woche - deshalb hier jetzt als Tip von mir für dich(/euch) 😉 - macht (mir) echt Spaß.

Von den Einführungstutorials halte ich ehrlich gesagt weniger als von Büchern - aber vielleicht ist das Geschmackssache. Ganz anders sieht das für mich jetzt, da ich mich ein bisschen mit der Materie beschäftigt habe, mit speziellen Themen wie bestimmten Packages für Python aus, bei der ich gerne mal schnell ein Tutorial (grob) durcharbeite - aber das spielt jetzt erst mal für dich wahrscheinlich (noch) keine Rolle. Die Bücher kann man an deinem Institut / deiner Uni oder sonst wo in der großen Hauptstadt 100%ig ausleigen - ansonsten kannst du ja sagen, dass man das in der übelsten Provinz Tübingen ja sogar bekommt... das wollen die sich bestimmt nicht sagen lassen müssen und besorgen es spätestens dann 😉.

Viel Erfolg und vor allem Spaß,

halt' uns auf dem Laufenden und gib' uns Tips wenn du was cooles entdeckst,

Gruß,

Pa_trick17

ich komm' da jetzt mal mit 'nem ganz anderem selbstlerneransatz (mit dem, den ich gefahren bin, und das, wie ich denke immerhin mit etwas erfolg) - immerhin kostet der einen heutzutage nur stromkosten und zeit:

1. google "'programmiersprache' + tutorial", und dann erstmal lesen, und verstehen versuchen, was da wie gemacht wird. gerne auch texte/artikel über assembler lesen, nur um zu verstehen was eine cpu ist und wie sie funktioniert und warum. das ist selbst für "einfache" sprachen wie basic oder phython wichtig, das man z.b. lernt, das fliesskommazahlen begrenzte genauigkeit je nach ihrer grösse haben, oder integerzahlen ab einer bestimmten grösse einen overflow haben, und man eventuell bibliotheken für grosse zahlen bei manchen dingen benutzen muss - man sollte schon etwa wissen, mit was für werkzeug man arbeitet, nicht das man mit einer stumpfen axt versucht einen baum zu fällen, weil sie ja gestern schon so eine nette kerbe in die runkelrübe gehau'n hat.

2. noch mehr artikel & tutorials lesen (ich weiss, die meisten sind sehr schlecht/unvollständig, aber viele kaputte sachen ergänzen sich immerhin gegenseitig) bis man die ersten kleinen programme selbst zusammengehackt hat, kompilieren konnte und sie auch funktionieren wie man's sich gedacht hat. foren sind auch super, nicht nur um gelangweilte "cracks" mit anfängerfragen zu nerven, sondern vor allem um die archive zu durchstöbern, und jedesmal ein fitzelchen mehr zum gesammten verständniss hinzuzufügen.

3. jetzt (und auch vorher schon, zwischendurch zur "entspannung") jede menge sources, erstmal von kleineren, dann von grösseren projekten, 'runterladen und _lesen_. ja, richtig durchlesen, wie ein verhyperlinktes buch (die suchfunktion ist praktisch um funktionen, die irgendwo benutzt werden, zu finden, etc.). die grundkenntnisse in der programmiersprache hat man ja schon durch die "tutorials" hoffentlich erlangt, ansonsten findet man mit google und "man" die schnittstellendokumentationen zu den bibliotheken, die (ja grade unter linux extrem gerne und viel) verwendet werden. am besten man passt die programme die man da analysiert den eigenen vorstellungen an, z.b. wenn man spiele programmieren will, kuckt man (nach dem typischen konsolenzeug) erstmal einfache bildschirmschoner an (um zu lernen, wie man grafik/animation macht), dann kleinere spiele und arbeitet sich vor bis zu den gediegeneren projekten; 75% der zeit sollte man am anfang mit "durchsieben" von im netz kursierenden "tutorials" verbringen, bis man auch kapiert was warum gemacht wird!

4. dann beschäftigt man sich mit den bibliotheken, die einem zwischendrin aufgefallen sind und gefallen haben, und sucht wieder tutorials, die sie erklären, beispielprogramme und projekte, die diese bibliotheken nutzen.

5. dann versucht man sich langsam an eigenen "projektchen" wobei's wichtig ist, erstmal vorhandene einfache sachen nachzumachen, und dann bei komplett eigenen vorher sehr gut zu planen. was viele leute (und tutorials) bei'm thema programmierung übersehen, ist das das ganze "spiel" eben nicht nur aus sprachsyntax und systemverständniss besteht, sondern auch aus kreativem und systematischem ordnen der elemente, die man produziert. man sollte siche schon vorher im kopf/auf papier genau überlegen, wie das programm strukturiert ist, und bei anderen opensourceprojekten keine scheu beim "abkupfern" von konzepten kennen, vorrausgesetzt, man versteht in etwa, warum sie angewendet wurden.

6. zurück zu punkt 1., nur diesmal einen level höher... 😉

so kann man's lernen, aber es kostet _viel_ zeit und geduld, je nachdem, was man erreichen will - man muss es schon wirklich wollen, und eine vision davon haben, was man mal damit machen will (die kann auch in dem lernprozess wachsen)! ich glaube übrigends, das man z.b. mit guten c/c++ kenntnissen schnell auch auf andere sprachen einsteigen kann, dann aber schon ein wesentlich besseres verständnis hat, was wie funktioniert. auch wenn die meisten leute sagen, python erst, dann anderes, sage ich: erstmal assembler ankratzen, dann c/c++, dann weiss man auch was und wie bei "hochsprachen" passiert, und baut nicht so viele "versteckte" fehler, die, wie ich denke, viele anfänger bis zur aufgabe demotivieren können - und schreibt in der hochsprache auch später wegen des besseren verständnisses der zusammenhänge wesentlich "bessere" programme. ist halt "hart", aber man muss ja nicht gleich den ganzen kernel verstehen wollen!

ich wünsch' jedem, der den "zahlenpinsel" bedienen lernen will viel glück und ausdauer!

Ja TraumFlug - den Weg bin ich auch gegangen. Und es hat sich gelohnt !

Aber, das war bei mir nicht der Einstieg, sondern erst vieeel später.
Der Einstieg war bei mir die hartnäckige Auseinandersetzung mit "Hello World" und dem Handbuch.

Ok, damals bei mir mit ALGOL60 und Lochkarten (ja, damals in den 70-ern .. 😬 ), aber vom Prinzip her genau dies durchbeißen
anhand der üblichen Handbücher. Deshalb glaube ich, dass das auch geht. Erstmal mit irgend einer Sprache anfangen,
die nächste Sprache ist dann kaum noch eine Hürde.

Und irgendwann will man dann auch wissen, wie Uby auf CPU-Register-Ebene funktioniert. Dann ist Assembler dran.
(siehe z.B. //forum.ubuntuusers.de/topic/moeglichkeit-um-in-60-sekunden-ausschalten-zu/ )

track

TraumFlug schrieb:

3. jetzt (und auch vorher schon, zwischendurch zur "entspannung") jede menge sources, erstmal von kleineren, dann von grösseren projekten, 'runterladen und _lesen_. ja, richtig durchlesen, wie ein verhyperlinktes buch (die suchfunktion ist praktisch um funktionen, die irgendwo benutzt werden, zu finden, etc.).

am besten man passt die programme die man da analysiert den eigenen vorstellungen an, z.b. wenn man spiele programmieren will, kuckt man (nach dem typischen konsolenzeug) erstmal einfache bildschirmschoner an (um zu lernen, wie man grafik/animation macht), dann kleinere spiele und arbeitet sich vor bis zu den gediegeneren projekten.

Wie konnte ich das vergessen! - Mach' ich auch sehr gern'.

Auch ansonsten sehr wertvolle Tips finde ich, auch von den Posts vorher - und wie du vielleicht erkennen kannst sehr unterschiedliche Ansätze ... . Vielleicht ist der beste Tip von dem her betrachtet ja auch: "Finde deinen eigenen Weg!", wobei man bei anderen die den Weg gerade gehen oder schon gegangen sind ja durchaus etwas Anregung zum Ausprobieren holen kann.

Von mir auch viel Erfolg und vor allem Spaß an dich und

alle, die den Zahlenpinsel bedienen lernen wollen

(sehr schön ausgedrückt, TraumFlug ☺)

Pa_trick17

P.S.: Find' es gut, dass es jetzt mal einen etwas konstruktiveren Thread zum Einsteigen ins Programmieren gibt und (noch?!) kein Programmiersprachenbashing. Vielleicht ist ja jeder Weg einer der vielen richtigen?!

Hi!

Auf jeden Fall sehr viele interessante und vor allem unterschiedliche Ansichten und Methoden sind hier zu lesen. Ich bin auch positiv überrascht, dass bislang keinerlei Diskussionen abgesehen vom eigentlichen Thema ausgebrochen sind.

Momentan kann ich zu den ganzen tollen Beiträgen gar nicht so unglaublich viel sagen, außer, dass sie mir sehr geholfen haben (denke ich ☺). Wie ich das nun genau angehe, werde ich sehen. Wegen der baldigen Ürpfungen fehlt mir derzeit ohnehin die Zeit dazu, danach kann ich mir alles mal in Ruhe ansehen... In jedem Fall befinde ich mich Dank euch in der angenehmen Situation, dass ich nun mehrere sehr vielversprechende Herangehensweisen an das Thema kenne. Sicherlich wird bei mir demnächst erstmal ein Buch ins Haus fliegen, denn momentan scheint es mir am sinnvollsten, mehrere eurer ansätze zu kombinieren und auf diesem Wege zu sehen und auszusieben, was mir liegt und was nicht.

Grüße, Sum

Hi Sum,

viel Erfolg bei den Prüfungen und viel Spaß danach mit dem Kombinieren und Aussieben der Ansätze - hört sich imo vernünftig an.

Hab' den Thread mal als "gelöst" markiert.

Gruß,

Pa_trick17