Programmiersprache für Anfänger

[rmoe]

die Frage ist, wo grenzt man "programmieren" (als handwerkliche Tätigkeit) von Softwaredesign und Architekturfragen ab.

Auf die frühzeitig die Antwort zu erarbeiten ist, ja. Weil es entscheidend ist, ob ich Architekt oder Bauingenieur werden will. Als Software-Architekt muss ich natürlich solide Kenntnisse über die Materialien und Werkzeuge des Programmierens haben, aber ich muss nicht wissen (und schon gar nicht aus dem FF), wie alles handwerklich umzusetzen ist. Als Programmierer wiederum muss mich das große Ganze nicht so interessieren sondern die (je nach Schwerpunkt) optimale Implementation.

Interessant, das als kurzen Abstecher, finde ich übrigens die Frage der Programmiersprache. Architekten sind diesbezüglich oft ignorant und oberflächlich, während Programmierer dazu neigen, alles mit "ihrer Sprache" machen zu wollen. Genau das - und die wirre Annahme, Programmierer könnten natürlich auch Architektur - dürfte aber eine der wesentlichsten Quellen für Probleme sein.
Da wird zum Beispiel großzügig ignoriert, dass C, ein absolut wunderbares Werkzeug für Arbeiten nah an der Hardware, zugleich eine zuverlässige Quelle für Probleme und übrigens auch krasse Ineffizienz bei vielem anderen ist. Andererseits meinen Ada-Leute allen Ernstes, man könne mit Ada (zumal moderneren Versionen, z.B. 2005) auch nah an der Hardware arbeiten; und das obwohl Ada von Anfang an sogar eine recht brauchbare und bequeme Schnittstelle zu C bietet. Oder man denke an die Horden von java-Jüngern, die, grob gesagt, noch nicht mal den raison d'etre und die Limits ihres Spielzeugs begriffen haben.

Ein anderes Problem liegt in der Untugend, ohne Verstand als allgemeingültig nachzuplappern und zu propagieren, was man gestern bei Google oder fatzebuk als hype-Weisheit aufgeschnappt hat. Beispiel: Ein guter Programmierer kann etliche Sprachen (impliziert: brauchbar gut) und wählt für ein Projekt die am besten geeignete aus. Papperlapp! Die Realität sieht anders aus, sehr anders. Und das wird noch erheblich verstärkt durch tool-hype und vorhandene "Produktionsstraßen" in größeren Firmen.
Dabei wird auch übersehen, was ich persönlich geradezu als Reife-Merkmal bei Studenten sehe: Ein(ig)e Sprachen rundweg abzulehnen oder gar zu hassen - und zwar konsistent und wohl begründet.

Im Endergebnis würde ich heute folgende Grundregeln im Sinne einer guten Grundausrüstung mit auf den Weg geben:
- C. Nicht perfekt, nicht mal unbedingt gut, aber verdammt gut genug, um Sourcen lesen und lokal verstehen zu können.
- Eine streng und statisch typisierte imperative (optional und bevorzugt (aber *nicht* nur) OO) Sprache. Diese gut durchkauen und verdauen und üben und das bis zum Ende, bis zu einem guten Reifegrad.
- Eine funktionale Sprache. Darf auch eine nicht ganz reine sein, Ocaml z.B. Muss man einfach mal gesehen und ausprobiert und konzeptionell geistig durchdrungen haben.
- Python. Als Alltagswerkzeug. Als Werkzeug zum Schaffen von kleineren oder momentan gebrauchten Werkzeugen. Aber auch aus Zen Gründen.
- FreePascal. Vielleicht bis hinten, bis zur Expertise, aber allemal bis zu "kann ich ordentlich und brauchbar effizient nutzen". Kann auch Punkt 2 ersetzen.


@ninti

Schau dir mal deine Fragen an. Und dann leg deine Ausführungen zu Themen, in denen du noch Schüler und Theoretiker bist daneben. Ich traue dir zu, meine Anmerkung von gestern dann zu verstehen.

 

[ninti]

Ein guter Programmierer kann etliche Sprachen

Das scheint mir eher eine Rolle für einen Hacker zu sein, der ja etliche Programmiersprachen kennen muss und sich dann eine auswählt, welche am besten zum "Problem" passt.

Ich weiß auch nicht, woher die Leute haben, dass Architekten = Programmierer sind?
Ist wie Autodesigner = Mechaniker. ^^

Ich habe auch letztens mitgekriegt, dass die vielen Programmiersprachen auf C aufbauen!

 

[rubricanis]

Ich habe auch letztens mitgekriegt, dass die vielen Programmiersprachen auf C aufbauen!

Das ist so einfach nicht richtig sondern trifft nur für eine bestimmte Klasse von Sprachen zu. Das ist so ähnlich als würdest du sagen alle Sprachen bauen auf Latein auf. Natürlich, letztlich generieren alle Maschinencode, haben aber einen sehr unterschiedlichen Zugriff auf den Prozessor. Lisp oder Forth sind z.B. genau so alt wie C aber ganz anders. Hinzu kommen unterschiedlichste Implementierungstechniken und manches mehr. Also ich wäre zurückhaltend mit solch pauschalisierenden Aussagen. Die Welt ist immer weit größer als der eigene Gesichtskreis.

 

[Kamikaze]

…
Von Konzept her sagt printf in C das gleiche wie print glaub das war Python?

Nein.

Aber was ich meine ist eher die genaue Syntax.
Außerdem was will man da auch viel von Konzepten lernen? Es gibt einen Eingang und einen Ausgang.

Nein.

Speicher wird belegt und wieder freigemacht.

Nein.

Und wie ich schon sagte, Algorithmen und Datenstrukturen sind irgendwie wie eine Sprache in der Programmiersprache selber.

Auch nein.

Ist wie Mathe, das du eben fürs Coden brauchst.

Eher für die Algorithmen als fürs Coden.


Ich glaube der „Ich will X lernen” Ansatz funktioniert bei Dir nicht.

Suche dir ein konkretes (kleines) Problem das Du lösen willst. Suche Dir das passende Werkzeug (Sprache) und frickel was. Dann schau was Du damit noch für Probleme lösen kannst. Vielleicht funktioniert Learning by doing für Dich ja besser.

 

[Daemotron]

Kannst du da ein Buch empfehlen? Weil ich mit meinem Buch manchmal durchdrehe, weil die Formeln mir nichts sagen.

Wirklich empfehlen kann ich Dir nichts, da ich Deinen Kenntnisstand nicht kenne und nicht weiß, wo Deine persönlichen didaktischen Präferenzen liegen. Ich selbst bin immer wunderbar mit Peter Stingl's "Mathematik für Fachhochschulen: Technik und Informatik" gefahren, allerdings natürlich mit einer älteren Ausgabe (5. Auflage oder so). Wird immer noch verlegt und ist wohl mittlerweile bei der 8. Auflage angekommen.

Na ja, ich bleibe schon bei C99, da es wohl der Standard ist.
Wird überhaupt noch ANSI verwendet?

*seufz* ok, einmal gehe ich noch drauf ein. Es gibt zwei große Gruppen von C Standards. Der eine Standard ist der gute, alte K&R Standard (K&R-1), der eben in deren Buch (Erstauflage von 1978) beschrieben wurde. Danach übernahm dann das American National Standards Institute (kurz: ANSI) die Standardisierung der Sprache C und schuf mit ANSI X3.159-1989 den ersten verbindlichen Standard (auch bekannt als C89). Ein Jahr später wurde die Standardisierung von C dann international aufgehängt; es übernahm die Internation Organization for Standardization (kurz: ISO). Alle folgenden Standards (C90, C95, C99 und C11) sind also eigentlich ISO Standards, werden aber immer wieder auch als "ANSI C" bezeichnet (was ansich aber nicht ganz richtig ist). Wenn Du also von "der Standard" sprichst, müsstest Du C11 nutzen, da es der letzte verabschiedete ISO-Standard ist.

Worauf ich mich aber bezog, war nicht der Standard (wir haben damals überwiegend noch mit C89 gearbeitet, da für neuere Standards schlicht die Compiler fehlten). Vielmehr ging es mir in meiner Aussage um die Notation. Hier gibt es zwei Stile: der eine ist bekannt als K&R und nutzt eine relativ kompakte Notation. Der andere Stil ist bekannt als Allman, BSD oder eben ANSI Stil und nutzt eine weniger kompakte Notation, welche die Lesbarkeit des Codes fördern soll.

 

[ninti]

wo Deine persönlichen didaktischen Präferenzen liegen.

Ein C Buch zu verstehen
Meine Kenntnisse reichen bis 2 + 2 = 4
2 * 2 + 2 = 6

Ich werde mir aber bestimmt das Buch zulegen. Danke!

Wird überhaupt noch ANSI verwendet?
Hast du das beantwortet? Ich kann das nämlich bei deiner Antwort nicht finden.
Und ich weiß schon, dass es ANSI und ISO gibt, deshalb frage ich mich, ob überhaupt ANSI C benutzt wird?
Wenn nicht gerade irgendwo beim Kernel oder alten Programmen.

Suche dir ein konkretes (kleines) Problem das Du lösen willst. Suche Dir das passende Werkzeug (Sprache) und frickel was. Dann schau was Du damit noch für Probleme lösen kannst. Vielleicht funktioniert Learning by doing für Dich ja besser.

Wie soll ich das mit learning by doing verstehen?

 

[Lotos]

Vielen Dank für die zahlreichen Anregungen und Ratschläge.

@rmoe:

Du hast in einem deiner letzten Beiträge einige Sprachen empfohlen. Ich würde gerne wissen, warum man ausgerechnet FreePascal und Python (und nicht zum Beispiel Lua und XY) lernen sollte, was Du mit "Zen Gründen" meinst und weshalb man OCaml durchdrungen haben sollte.

Die anderen Punkte kann ich nachvollziehen bzw kann ich mir vorstellen, wieso sie wichtig sein könnten (Konzepte lernen und C, um den Code von vielen Programmen lesen zu können), würde aber trotzdem gerne noch deine Begründung dazu lesen.


Leider muss ich schon wieder aufhören. Ich schreibe in den nächsten Tagen einen ausführlicheren Beitrag. Vielleicht wird dieser Thread dann eines Tages dem ein oder anderen Grünschnabel genauso sehr helfen wie mir.

MfG karotte

 

[Azazyel]

Auf die frühzeitig die Antwort zu erarbeiten ist, ja. Weil es entscheidend ist, ob ich Architekt oder Bauingenieur werden will.

Beide sollten aber auf jeden Fall einmal auf einer Baustelle gearbeitet haben, regelmäßig dort vorbeischauen und wissen, was Stand der Technik ist.

Als Software-Architekt muss ich natürlich solide Kenntnisse über die Materialien und Werkzeuge des Programmierens haben, aber ich muss nicht wissen (und schon gar nicht aus dem FF), wie alles handwerklich umzusetzen ist.

Ein Software-Architekt sollte aber aus eigener Erfahrung wissen, was mit welcher Technik wie gut oder schlecht umsetzbar ist. Daran hapert es in der Praxis sehr häufig und führt oftmals zu katastrophalen Architekturvorgaben.

Als Programmierer wiederum muss mich das große Ganze nicht so interessieren sondern die (je nach Schwerpunkt) optimale Implementation.

Das funktioniert in der Praxis nicht. Als Entwickler läuft man automatisch in die Defizite einer Architektur bzw. merkt meist als erster, wenn die Architektur nicht mehr passt (weil z.B. geänderte Anforderungen eine Anpassung der Architektur erfordern). Das Wasserfall-Modell "Architekt entwirft, Entwickler setzt blind um" scheitert in der Praxis jeden Tag aufs Neue und ist nicht umsonst seit über 10 Jahren nicht mehr Stand der Technik.

Genau das - und die wirre Annahme, Programmierer könnten natürlich auch Architektur - dürfte aber eine der wesentlichsten Quellen für Probleme sein.

Die einzig guten Software-Architekten, die ich jemals kennengelernt habe, waren zumindest einmal hervorragende Entwickler. So gut, dass ich sie jederzeit als Entwickler ins Team nehmen würde, auch wenn sie nicht mehr jedes Detail im Kopf haben.

Umgekehrt können Software-Architekten, die keine Ahnung von Programmierung haben, keine guten Software-Architekten sein. Der berühmte Elfenbeinturm.

Ein guter Programmierer kann etliche Sprachen (impliziert: brauchbar gut) und wählt für ein Projekt die am besten geeignete aus. Papperlapp! Die Realität sieht anders aus, sehr anders.

Stimmt. Es gibt nur noch wenig 1-Mann-Projekte, in denen der Entwickler auf der grünen Wiese entscheidet, welche Programmiersprache verwendet wird. Auf der anderen Seite gibt es Entwickler die glauben, sie beherrschen ein Dutzend Programmiersprachen - und sind zu doof zu realisieren, dass sie keine einzige beherrschen.

Und das wird noch erheblich verstärkt durch tool-hype und vorhandene "Produktionsstraßen" in größeren Firmen.

Unsere Freunde "das neueste Spielzeug" und "wenn ich nur einen Hammer habe, sieht jedes Problem wie ein Nagel aus".

Dabei wird auch übersehen, was ich persönlich geradezu als Reife-Merkmal bei Studenten sehe: Ein(ig)e Sprachen rundweg abzulehnen oder gar zu hassen - und zwar konsistent und wohl begründet.

"Studenten" und "Reife" würde ich nicht in einem Satz verwenden. Ein Student wird nur mit einem sehr überschaubaren Satz an Problemen und Anforderungen konfrontiert, die bestimmte Vor- und Nachteile der jeweiligen Programmiersprachen extrem verstärken bzw. teilweise komplett kaschieren. Solange man eine Programmiersprache nicht in einem realen Projekt eingesetzt hat, hat man bestenfalls eine mehr oder minder begründete Meinung, aber nicht die Grundlage zu einem fundierten Urteil.

Andererseits birgt der Ansatz "ich habe zwar keine Ahnung, aber trotzdem eine Meinung" natürlich die besten Voraussetzungen für die nächste Generation von Elfenbeinturm-Architekten.

And now for something completely different:

Wie soll ich das mit learning by doing verstehen?

Du kannst noch Monate mit dem Lesen diverser Diskussionen über Vor- und Nachteile der jeweiligen Programmiersprache verbringen und dich mit tonnenweise Theorie beschäftigen, ohne eine einzige Zeile Quellcode hervorzubringen. Danach kannst du hervorragend über Programmiersprachen referieren, aber immer noch nicht programmieren.

Oder du fängst jetzt einfach an und probierst es aus. Dein erstes Programm wird haarsträubend schlecht sein, aber das ist bei jedem Programmierer so. Dann hast du eine Grundlage, um dir über alles andere Gedanken zu machen.

Natürlich habe auch ich meine Meinung über die Vor- und Nachteile der einzelnen Programmiersprachen, aber ich will dich damit nicht langweilen. Nimm einfach Python und fang heute noch an.

 

[rmoe]

Azazyel

(Architekt oder Bauingenieur )

Beide sollten aber auf jeden Fall einmal auf einer Baustelle gearbeitet haben, regelmäßig dort vorbeischauen und wissen, was Stand der Technik ist.

Ja, sollten sie. Tatsächlich sollte die Ausbildung wohl zu ca. 80% die gleichen Inhalte umfassen. Der Unterschied liegt darin, was später die Aufgaben sind und demzufolge die jeweiligen Perspektiven, aus denen man auf ein Projekt schaut. Und darin, wie jemand tickt und ob ihm besser die Planung komplexer Mechanismen liegt oder besser die Implementierung relativ kleiner Einheiten auf und in einer ebenfalls komplexen Maschinerie (CPU, OS, ...).

Ein Software-Architekt sollte aber aus eigener Erfahrung wissen, was mit welcher Technik wie gut oder schlecht umsetzbar ist. Daran hapert es in der Praxis sehr häufig und führt oftmals zu katastrophalen Architekturvorgaben.

Selbstverständlich. Ich habe es Studenten öfter mal so erklärt: Ein guter Softwarearchitekt könnte seinen Entwurf auch selbst implementieren, wenn auch ineffizient und nur qualitativ mittelmäßig. Und ein guter Programmier könnte auch entwerfen, wenn auch ineffizient und qualitativ mittelprächtig (jeweils bezogen auf nicht triviale Projekte/Jobs).

Das funktioniert in der Praxis nicht. Als Entwickler läuft man automatisch in die Defizite einer Architektur bzw. merkt meist als erster, wenn die Architektur nicht mehr passt (weil z.B. geänderte Anforderungen eine Anpassung der Architektur erfordern). Das Wasserfall-Modell "Architekt entwirft, Entwickler setzt blind um" scheitert in der Praxis jeden Tag aufs Neue und ist nicht umsonst seit über 10 Jahren nicht mehr Stand der Technik.

Pardon, nein. Das funktioniert sehr oft nicht, weil wir nur sehr wenige gute Architekten haben. Das sind sehr häufig CASE oder UML oder model-of-the-week Plauderer, die, Verzeihung, noch nicht mal ihren Daseinsgrund im Job geistig durchdrungen haben. Was du da von notwendigen Architekturanpassungen erzählst ist, Pardon, einfach nur ein krasses Beispiel für grobe Inkompetenz der Architekten.
Und das Modell ist schon lange nicht mehr "Stand der Technik" aus zwei Gründen:
Zum einen, weil, vor allem aus den usa, immer neue Schwachsinnswellen zu uns rollen, die hier kenntnislos aber begeistert aufgenommen werden; die werden häufig nur deshalb nicht als Schwachsinn erkannt, weil die nächste Welle schon rollte, ehe die aktuelle als Unsinn erkannt wurde.
Zum anderen, weil wir so wenige gute Architekten haben (und eine nicht gerade qualitative Ausbildung *räusper), was dazu führt, dass das dann eben von den Programmierern erledigt wird. Was aber nur von bescheidenem Erfolg ist weswegen Tür und Tor für die nächste Schwachsinnswelle offensteht.

Die einzig guten Software-Architekten, die ich jemals kennengelernt habe, waren zumindest einmal hervorragende Entwickler. So gut, dass ich sie jederzeit als Entwickler ins Team nehmen würde, auch wenn sie nicht mehr jedes Detail im Kopf haben.

Angesichts der akuten Qualitätsmangels an deutschen Unis bleibt das in der Tat erschreckend häufig der einzige Weg, also Architekten, die lange als Entwickler gewachsen und gereift sind und da Zeug (und die Gelegenheit) dazu haben und Architekten werden. Meist, um ehrlich zu sein, nicht die allerbesten, einfach weil Grundlagen fehlen, aber allemal viel besser als das Gros der "Architekten", die Unis produzieren.
Interessante Frage am Rande: Warum, verdammt, holt man nicht öfter mal altgediente, erfahrene, gereifte Entwickler an die Unis?

Umgekehrt können Software-Architekten, die keine Ahnung von Programmierung haben, keine guten Software-Architekten sein. Der berühmte Elfenbeinturm.

Na ja, das ist so frappant offensichtlich, dass man es gar nicht erwähnen muss.

Stimmt. Es gibt nur noch wenig 1-Mann-Projekte, in denen der Entwickler auf der grünen Wiese entscheidet, welche Programmiersprache verwendet wird. Auf der anderen Seite gibt es Entwickler die glauben, sie beherrschen ein Dutzend Programmiersprachen - und sind zu doof zu realisieren, dass sie keine einzige beherrschen.

Vorsicht! Ein wesentliches Credo all der Schwachsinnswellen aus den usa war und ist ja, dass ein ächta Programmiera mehrere, eigentlich sogar viele Sprachen können muss. Da das wenig mit der Realität zu tun hat, bleibt vielen nur zu faken und "habch ma von gelesen" zu verkaufen als "kenn ich, kann ich".
Zugleich eröffnet das eine zweite Gefahr, die nämlich, das auch bei Architekten als negativ zu werten. Und das ist es nicht (das ist mal einer der Punkte, wo wirklich ein Unterschied ist). Wenn ein Programmier sagt, dass er ABC kann, dann heisst das für mich, dass er spätestens nach 1 Woche wieder voll drin ist. Wenn ein Architekt das sagt, dann heisst das für mich, dass er einen Mechanismus auch so spezifieren kann, dass ABC-Programmierer was damit anfangen können. Und, viel wichtiger noch, es heisst, dass der Architekt sich ausreichend genug mit der Sprache beschäftigt hat (wenn auch meist theoretisch), dass er sie sinnvoll einordnen kann und um Eigenheiten, Schwächen und Stärken weiss und sie konzeptionell ordentlich kennt.

"Studenten" und "Reife" würde ich nicht in einem Satz verwenden.

Da verstehe ich dich sehr gut. Aber zum einen meinte ich "Reife" relativ, zum anderen ging es bei meinen Studenten um ausgewachsene diplomierte Leute mit im Schnitt mindestens 5 Jahren Berufserfahrung.
Der Schwerpunkt meiner Aussage war: Du darfst gerne 2 oder 3 Sprachen ablehnen, sogar hassen. Aber ich will gut durchdachte, fundierte Gründe dafür (was für mich als Ausbilder auf's selbe hinuslief wie "Ich mag ABC, weil ..." - Wesentlich war mir die erkennbar fundierte und ausgiebige und möglichst auch intelligente Befassung mit und Betracht der gehassten (oder geliebten) Sprache).

(And now for something completely different: ... Ich bin mir mittlerweile nicht mehr so sicher, dass es dem je wirklich ums programmieren lernen ging ...)

 

[rmoe]

Du hast in einem deiner letzten Beiträge einige Sprachen empfohlen. Ich würde gerne wissen, warum man ausgerechnet FreePascal und Python (und nicht zum Beispiel Lua und XY) lernen sollte, was Du mit "Zen Gründen" meinst und weshalb man OCaml durchdrungen haben sollte.

Es geht nicht spezifisch um Ocaml sondern um funktionale Sprachen. Ocaml ist nur (mMn berechtigt) ziemlich beliebt und relativ soft.

Warum funktionale Sprachen? Weil sie in wichtigen Punkten ganz anders ticken. Weil manches damit dimensional besser zu machen ist. Weil erwachsene Programmierer auch Hype von Tatsachen unterscheiden können müssen (und es gibt reichlich Hype um funktionale Sprachen).
Ausserdem kann man damit hübsche (von Studenten gern als fies empfundene aber sehr lehrreiche) Spielchen treiben, z.B. "Und jetzt setzen Sie das mal non-funktional, imperativ um".

FreePascal empfehle ich, weil Wirthsche Sprachen nach wie vor eine wichtige und qualitativ hochwertige Familie sind. Leider sind aber auch fast alle moderneren Inkarnationen zu Exoten geworden angesichts der riesigen C++ und java Welle. Pascal (so ziemlich die älteste) dagegen genießt immer noch rege Unterstützung und, was gerade beim Lernen wichtig ist, Pascal bietet auch eine komplette nette IDE und ganz praktische Anwendbarkeit. GUI front-ends z.B. lassen sich damit recht flott und qualitativ brauchbar machen. Und es gibt reichlich libraries. Nicht zuletzt weiss ich aus Erfahrung, dass es Lernende beflügelt erreichbare Ergebnisse und Erfolge zu sehen (sprichwörtlich. Also was auf dem Monitor).

Python weil es - berechtigt und verständlich - äusserst beliebt ist und praktisch und produktiv und gut unterstützt und geradezu überschüttet mit libraries und es läuft auf so ziemlich allem. Dazu kommt, dass Python einige brillante Konzepte im Inneren hat und eben *nicht* schnell mal gehackt sondern sehr gekonnt und intelligent und klug erdacht und konzeptioniert wurde. Und natürlich ist es vielseitig einsetzbar.

lua ist nett und klein und praktisch, aber aus der großen Perspektive viel weniger bedeutend und bahnbrechend. Ich würde es nicht gerade empfehlen, aber ich würde auch niemandem ausdrücklich abraten davon (wie z.B. von perl oder php).

Nicht zuletzt:

Die zugrunde liegende Frage hat ja zwei wesentliche Komponenten. Zum einen "ich will programmieren lernen". Zum anderen (vielleicht von mir falsch impliziert) die Frage nach professioneller Nutzung.

Python gehört für beides zum attraktivsten, auch in pragmatischer Hinsicht (IDE, community, etc ...). Zugleich gehört Python aber auch zu den Sprachen, die ein professionelles Modul abdecken. Will heissen: Im professionellen Bereich wird man nicht viele Sprachen können (wirklich können) müssen, aber zumindest eine "Hauptsprache", i.d.R. eine compilierte Sprache, die weite Bereiche abdeckt. Und daneben noch eine "quick shot", "tool" Sprache, mit der man schnell mal ein Werkzeug oder ein Interface bauen kann oder einen http server oder ...

Pascal wird heute in aller Regel keine Verwendung in größeren Projekten finden (wobei es durchaus Ausnahmen gibt) aber darum geht's beim Lernen nicht unbedingt. Ein modernes Pascal kann aber so ziemlich alle Grundlagen vermitteln und es ist praktisch erlernbar, bewährt (auch als Lernsprache) und wer Pascal ordentlich kann, der hat eine gute Ausgangsbasis. Ganz nebenbei und für einen Anfänger nicht unwichtig, begünstigt Pascal das Basteln schwerwiegender Sicherheitsprobleme deutlich weniger als z.B. C++ (wohl nicht zufällig sind alle nennenswerteren Projekte, die heute in Pascal gemacht werden, sicherheitssensibel, z.B. öffentlicher Transport).

 

[Athaba]

Von den Anforderungen wäre vielleicht Go oder Rust ganz interessant. Ich hoffe ich klinge jetzt nicht wie jemand, der das empfiehlt was gerade gehyped wird, aber wenn ich an die drei Anforderungen denke, dass sie kompilierbar sein soll, dass sie Low Level sein soll und es trotzdem was für Websites ist, dann klingt Go wohl interessant. Noch dazu ist die Sprache recht klein (anders als Skriptsrpachen) und man muss sich nicht übermäßig mit Unicode ärgern (was im Webbereich nett sein kann). Rust ist denke ich zu neu, zu groß und die Tutorials machen glaube ich mehr Sinn, wenn man C++ oder so kennt. Wenn man aber wirklich Low Level gehen will ist das spannend. Es gibt mindestens eine Uni da wird Rust für OS-Entwicklung verwendet (aber ehrlich gesagt würde ich da eher C nehmen).

Ansonsten gibt es die typischen Sprachen mit denen viele beginnen: C, Python, JavaScript. Python und JavaScript sind für Web-Applikationen spannend, C wenn du wirklich wissen willst was passiert, aber darauf greift man im Web eher recht selten zurück.

Kleiner Tipp noch: Das Programmieren selbst ist weniger ein Skill, als das was du programmierst. Wenn du Variablen, Kontrollstrukturen, Operatoren, etc. kennst, dann war's das zu einem großen Teil schon, was du können musst um alles zu programmieren. Der Rest ist dann je nach Anwendungsfall. Da gibt's dann HTTP, HTML, Datenbanken, Netzwerke, OpenGL, Themen wie Machine Learning und Pattern Recognition, verteilte Systeme, Geospatial Information Systems, etc. die dann das eigentliche Wissen ausmachen.

Man glaubt am Anfänger oft, dass man X mit Sprache Y nicht machen kann, was aber eigentlich niemals der Fall ist (siehe auch Turing Completeness).

Noch ein Tipp: Nimm eine Sprache und verwende sie mal zwei, drei Jahre intensiv, bevor du was anderes probierst (aber tu das dann!). Wenn du eine Sprache gut kannst, dann fällt vieles einfacher, als wie wenn man immer hin und her springt.

Der Bekanntheitsgrad einer Sprache ist schon gewissermaßen wichtig, weil er aussagt auf wie viel Wissen und Bibliotheken du zurückgreifen kannst, was wiederum aussagt, was du damit machen kannst. Allerdings kann der auf Grund von Hypes oft täuschen. Um sich ein Bild zu machen gibt es zwei Möglichkeiten: Entweder man schaut sich die Anzahl der Module/Bibliotheken an oder man schaut sich von einem Thema, das einen interessiert an, ob es dazu in einer Sprache Bibliotheken gibt. Am Besten also ein Ziel vor Augen haben und einfach mal schauen, was die Leute die ähnliches tun so verwenden. Dann geht's leichter. Man kann sich später mal umentscheiden, aber da sollte man echt triftige Gründe haben, sonst hoppt man immer nur rum und lernt nur neue Syntax.

 

[Azazyel]

Was du da von notwendigen Architekturanpassungen erzählst ist, Pardon, einfach nur ein krasses Beispiel für grobe Inkompetenz der Architekten.

Zu Beginn eines Projektes sind niemals alle notwendigen Informationen vollumfänglich bekannt, geschweige denn Anforderungen, die erst Jahre später an die Software gestellt werden. Viele Erkenntnisse gewinnt man erst im Laufe der Entwicklung.

Bei Quellcode ist es inzwischen selbstverständlich, diese Realität anzuerkennen und Refactorings durchzuführen. Bei der Architektur muss man es genauso machen, will man nicht enorme Schmerzen erleiden.

Zum anderen, weil wir so wenige gute Architekten haben (und eine nicht gerade qualitative Ausbildung *räusper), was dazu führt, dass das dann eben von den Programmierern erledigt wird. Was aber nur von bescheidenem Erfolg ist weswegen Tür und Tor für die nächste Schwachsinnswelle offensteht.

Ich glaube nicht, dass es mit Ausbildung allein getan ist. Software Engineering hat als Disziplin noch nicht den Stand erreicht, dass wir Software wie Häuser am Reißbrett entwerfen könnten. Es wird zwar trotzdem regelmäßig probiert, aber ohne Feedback zwischen Architektur und Entwicklung kommt am Ende schlechte Software mit nicht mehr passender Architektur raus, wenn das Projekt nicht völlig scheitert.

Interessante Frage am Rande: Warum, verdammt, holt man nicht öfter mal altgediente, erfahrene, gereifte Entwickler an die Unis?

Welcher Professor möchte schon Konkurrenz mit Praxiserfahrung haben, die ihn durch ihren weiteren Horizont als realitätsfernen Vertreter des Elfenbeimturms dastehen lässt? Der Kontakt mit der Realität ist vielerorts gar nicht erwünscht. Die Eigenheiten der deutschen Hochschullandschaft mit verbeamteten Professoren und schwachem Mittelbau tut ihr übriges.

Da verstehe ich dich sehr gut. Aber zum einen meinte ich "Reife" relativ, zum anderen ging es bei meinen Studenten um ausgewachsene diplomierte Leute mit im Schnitt mindestens 5 Jahren Berufserfahrung.

Das ist eine Klientel, die ich - auch wenn für einen postgradualen Studiengang immatrikuliert - nicht mehr als "Studenten" bezeichnen würde.

Der Schwerpunkt meiner Aussage war: Du darfst gerne 2 oder 3 Sprachen ablehnen, sogar hassen. Aber ich will gut durchdachte, fundierte Gründe dafür (was für mich als Ausbilder auf's selbe hinuslief wie "Ich mag ABC, weil ..." - Wesentlich war mir die erkennbar fundierte und ausgiebige und möglichst auch intelligente Befassung mit und Betracht der gehassten (oder geliebten) Sprache).

Das unterschreibe ich sofort. Leider ist die Variante "ich hab zwar keine Ahnung, aber trotzdem eine Meinung ohne Zwischentöne" wesentlich verbreiteter.

 

[darktrym]

Ich versteh es nicht, wie jemand allen Ernstes heute noch Pascal empfehlen kann. Für die 80iger ok, strukturierter und klarer als C. Pascal bietet aber erstmal keine IDE noch GUI-Unterstützung. Ja damals hatten wie alle Turbo Pascal und später für die armen Schlucker FreePascal. Selbst heute wird man mehr Delphi-Leute vorfinden, die weiterhelfen können als Pascal-Freaks. Zurückgebliebene Lazarus-Kinder soll es angeblich auch geben, hab die nie in der freien Wildbahn gesehen.
Dazu fehlt der Sprache selbst die saubere Unterstützung von Referenzen und Objekten(nachgefrickelt in TP5.5). Und ja, ich mach einen Unterschied zwischen Delphi(ObjectPascal) und Pascal. Delphi ist in vielen Fällen wartbarer, schon alleine wegen der API, val und str - Willkommen in den 70giern.
Im Weiteren kommen Probleme der Gegenwart wie Unicode und weitere Altlasten. Die Entwicklung hat sich auch vollends aufgesplittet, aktive Projekte die auf eines der beiden noch setzen, gibts wenige. Dieses Pascal kann nicht mal ohne weiteres Tupel zurückgeben. Gängige Datenstrukturen wie Mengen, Listen, Tupel gibts erst gar nicht.Für Nerds und Historiker mag die Sprache heute noch relevant sein, anderswo bekommt man bestenfalls ein Mitleidslächeln oder Facepalm.

PS: Ich hab lange genug Pascal und später Delphi die Stange gehalten. Aber der Zug ist eigentlich auf dem Abstellgleis nach Delphi 7.
PPS: Entgegen den viel gepredigten Uni-Ansatz, halte ich nichts von irgendwelchen Nischensprachen zu lehren nur um Konzepte der Programmierung vorzuführen. Entweder beginne ich gleich mit dem besten und verbreitesten Werkzeugen und bereite die Leute auf die Arbeit vor oder ich zeig den Leuten, wie es nicht geht. Die Typen von Dozenten sind auf Unis zahlreich vorhanden. Manche wollen einfach nicht dazulernen und leben in ihren eigenen kleinen Kosmos.

 

[rmoe]

Zu Beginn eines Projektes sind niemals alle notwendigen Informationen vollumfänglich bekannt, geschweige denn Anforderungen, die erst Jahre später an die Software gestellt werden. Viele Erkenntnisse gewinnt man erst im Laufe der Entwicklung.

Ich kenne das, aber ich weiss auch, dass das letztlich Fälle sind, in denen die Architekten versagt haben. Und Fälle, in denen Software schlicht zu etwas vergewaltigt werden soll. Aber sogar das kann man mit gutem design halbwegs abfangen. Als Architekt mit praktischer Erfahrung gehört es schlicht zum job, sinnvolle Abschätzungen zu treffen und zu berücksichtigen, zumindest in Form von Anbaubarkeit.
Aber nochmals: Wenn man wesentliche Erkenntnisse erst im Lauf der Entwicklung gewinnt, dann hat man den falschen Architekten (wobei ich einräume, dass gute sehr rar sind).

Ich glaube nicht, dass es mit Ausbildung allein getan ist. Software Engineering hat als Disziplin noch nicht den Stand erreicht, dass wir Software wie Häuser am Reißbrett entwerfen könnten. Es wird zwar trotzdem regelmäßig probiert, aber ohne Feedback zwischen Architektur und Entwicklung kommt am Ende schlechte Software mit nicht mehr passender Architektur raus, wenn das Projekt nicht völlig scheitert.

Ohne feedback und gute Kommunikation zwischen den einzelnen Bereichen kommt in so ziemlich jeder Branche Mist raus.

Unser Problem ist, Entschuldigung wenn ich da mal deutlich werde, dass weiteste Teile der gesamten Branche us-amerikanisch geprägt (um nicht zu sagen beherrscht) sind und dass die amis keine Kultur und schon gar keine intellektuelle Kultur haben. Die können ihre unis in ihren Magazinen und Institutionen noch so hochfeiern und an die Spitze setzen, das ändert nichts an der Realität. Erschwerend kommt hinzu, dass in den usa alles kommerziell und Show-orientiert ist. Wenn da ein Großer etwas kackt, dann wird das zu Gold erklärt.
Im Nachbarland, in FR sieht es deutlich besser aus und auch die Schweizer haben noch nicht ganz vergessen, wie's geht.

Man *kann* ein - auch großes - Software Projekt ordentlich designen - aber nicht mit der gängigen Methode des Monats, nicht in der Annahme, eine egal wie tolle und teure toolchain könne menschlichen Geist, Wissen und Erfahrung ersetzen, und nicht mit religiösen Leitlinien (wie z.B. "1000 eyes").

Die Lösung liegt *nie* in zusätzlicher Komplexität - aber genau das ist letztlich der gängige Ansatz, egal wie hübsch man das verbrämt.

Mal ein kurzer Blick in die Realität: Ada, explizit entstanden, um die Entwicklung zu vereinfachen und die Herstellung zuverlässiger, sicherer software zu ermöglichen/begünstigen. Ein brillianter Ansatz, übrigens von einem Franzosen (J. Ichbiah). Und dann geschahen zwei Dinge: Zum einen wurde Ada weiter entwickelt, angepasst, ergänzt, weitenteils übrigens gut und mit Verstand. Zum anderen wurde Ada - typisch amis - gnadenlos verbürokratisiert und mit einem Standard erstickt, der nicht wirklich einer ist, der gigafett ist und der den Kern von Ada, die Schönheit und Konzeption ignoriert und nicht kapiert hat.

Ergebnis: Haufenweise Projekte werden in java und C++ gefummelt und erzeugen die Probleme, die du - völlig zurecht - beschreibst und beklagst.

Das ist eine Klientel, die ich - auch wenn für einen postgradualen Studiengang immatrikuliert - nicht mehr als "Studenten" bezeichnen würde.

Möglicherweise bin ich da altmodisch simpel, aber ich nenne jeden jenseits Abitur, den ich in einer entsprechenden Einrichtung ausbilde "Student". Relevant ist doch nicht, wie man diese Leute nennt, sondern was sie mitnehmen dabei.

 

[ninti]

Ein mal kurz nicht gecheckt und es gibt wieder 10 neue Beiträge hier.

Zum einen, weil, vor allem aus den usa, immer neue Schwachsinnswellen zu uns rollen, die hier kenntnislos aber begeistert aufgenommen werden; die werden häufig nur deshalb nicht als Schwachsinn erkannt, weil die nächste Welle schon rollte, ehe die aktuelle als Unsinn erkannt wurde.

Kann ich mich dann auf Bugs in der Software freuen?

Warum, verdammt, holt man nicht öfter mal altgediente, erfahrene, gereifte Entwickler an die Unis?

Die Standardantwort? Weil sie alt sind ^^ Die wollen dann natürlich auch mehr Geld und wer will schon mehr Geld zahlen?
Ich weiß nicht wie es bei den IT Leuten ist aber sonst ist das so die Regel.

Welcher Professor möchte schon Konkurrenz mit Praxiserfahrung haben, die ihn durch ihren weiteren Horizont als realitätsfernen Vertreter des Elfenbeimturms dastehen lässt? Der Kontakt mit der Realität ist vielerorts gar nicht erwünscht. Die Eigenheiten der deutschen Hochschullandschaft mit verbeamteten Professoren und schwachem Mittelbau tut ihr übriges.

Das kommt noch dazu. Es ist hart da draußen.

Noch ein Tipp: Nimm eine Sprache und verwende sie mal zwei, drei Jahre intensiv, bevor du was anderes probierst (aber tu das dann!). Wenn du eine Sprache gut kannst, dann fällt vieles einfacher, als wie wenn man immer hin und her springt.

Dem kann ich nur zustimmen, den am Ende kennt man die beiden, aber kann nicht wirklich gut mit den beiden Sprachen programmieren.
Mein Tipp dazu: Wenn du dir schon eine Sprache ausgesucht hast und du bist auch 100% sicher, dann lass es dir nicht ausreden.

Ich versteh es nicht, wie jemand allen Ernstes heute noch Pascal empfehlen kann.

Das habe ich mich auch gefragt, aber hey, ihr seid die IT-Profis.

Entweder beginne ich gleich mit dem besten und verbreitesten Werkzeugen und bereite die Leute auf die Arbeit vor oder ich zeig den Leuten, wie es nicht geht.

Da stellt sich mir auch gleich die Frage, will er mit der Programmiersprache eigentlich Geld verdienen oder eher ist das ein Hobby?

PS"Verzeiht, wenn ich dazwischen quatsche, wenn sich hoch professionelle Programmierer unterhalten, aber ich möchte auch gerne mitreden. Wenigstens nur um von euch etwas zu lernen.
Wer jetzt noch fragt, ich lerne bereits eine Programmiersprache."

 

[rmoe]

darktrym

Es geht mir nicht um "Stange halten", Mehr noch, ich wüsste eine Menge Dinge, für die man Pascal hassen kann.

Aber zum einen ist es (in seinen modernen Versionen (ObjectPascal)) eine bewährte Lehrsprache, zum anderen habe jedenfalls ich immer wieder festgestellt, dass aus Leuten, die mit Pascal anfingen, brauchbare Programmierer wurden (was mEn bei z.B. java anders aussieht) und zudem gibt es eine kostenlose und ziemlich komplette Spielwiese, auch wenn du eher aus Lazarus/Freepascal herabzublicken scheinst.

Ob man Tupel (bequem) zurückgeben kann ist letztlich Schnickschnack. Was mich in Sachen Ausbildung interessiert ist eine solide Grundlage und zumindest passable Erweiterbarkeit. Genau die, in Form von Stabilität, interessiert mich übrigens auch bei professionellen Projekten.

Mag ich Pascal, ich persönlich? Benutze ich es gern? Um Himmels willen nein. Aber darum ging's nicht.

 

[ninti]

rmoe: Ich erinnere mich, damals so vor 10 oder mehr Jahren war auch TurboPascal die Sprache für Anfänger.
Aber ich denke, kann man sie heute nicht durch Python ersetzen?

 

[rmoe]

(Ich versteh es nicht, wie jemand allen Ernstes heute noch Pascal empfehlen kann.)
Das habe ich mich auch gefragt, aber hey, ihr seid die IT-Profis.

Mögen tue ich Pascal auch nicht und ich halte es nicht mal für eine der attraktiveren Sprachen. Aber: Es war und ist immerhin gut genug für öffentliche Verkehrssysteme (mit ziemlich hohen Sicherheitsansprüchen).

Und überhaupt: Wer oder was bist du denn eigentlich, den Schnabel hier aufzumachen? Melde dich wieder, wenn du wenigstens mal einige zehntausend Zeilen in Pascal, in Python, in C, in ... programmiert hast.

 

[darktrym]

Als Anfänger fällts immer schwer das Taschenmesser zu finden, das alles löst; jeder hat da seine eigene Meinung. Eigentlich kann man nur empfehlen, nimm EINE Programmiersprache und beschäftige dich intensiv damit. Auch wenn ich jetzt auf Python schwöre, gibts genug Bereiche wo ich es nicht anwenden würde. Und wenn wirklich's nicht mehr geht und eine andere Sprache das Problem leichter löst, dann erweitere deinen Horizont. Denk nicht in Schubladen, weder OO noch funktional sind die Lösungen aller Probleme. Ob einen die Programmierung liegt, wird sich zeigen. Ich finde es zwiespältig gerade heute im Zweifel rat von Fremden und Foren zu holen. Was nützt einem eine Lösung die man nicht verallgemeinert woanders anwenden kann? Wir alten Säcke mussten damals in kalten Tagen viel investieren um uns zu bilden.Lies einfach ein Buch und setzte deine Projekte um. Wenn's läuft und du Kritik am Stil hast(selbst wenn nicht) stell das anderen zur Verfügung und bitte um Verbesserungsvorschläge. Die meisten Bücher beschreiben elementare Dinge, die den Leser nicht überfordern sollen.

Die Unis sind heute ein Musterbeispiel wie schlecht man Leute auf das Arbeitsleben vorbereiten kann. Heutige Absolventen lernen nicht strukt. Denken oder "Skills" sondern oft nur wie man einen Schein dafür bekommt. Die wenigsten werden Ocaml weiterverwenden können, akademisch interessant mehr nicht. Ich sehe es hier praktisch, wenn ich schon einsteige in diesen Kreis, dann will ich im Zweifel auch Antworten finden, die in der Praxis relevant sind. Javascript und C++ mögen nicht toll sein weder die Sprache noch als Einstieg, aber im Zweifel gibts mind. einen Deppen der vor dem gleichen Problem stand. Davon unterscheiden sich weder Hobby- noch Profi-Programmierer voneinander, programmieren heißt diszipliniert dabei zu bleiben.

 

[rubricanis]

Die Unis sind heute ein Musterbeispiel wie schlecht man Leute auf das Arbeitsleben vorbereiten kann. Heutige Absolventen lernen nicht strukt. Denken oder "Skills" sondern oft nur wie man einen Schein dafür bekommt.

Das Drama fängt viel früher an: Rationales Denken ist in weiten Gesellschaftsbereichen verpönt und gilt als 'kopfgesteuert', was es ja glücklicherweise tatsächlich ist. Unglücklicherweise setzt sich das in der Schule fort wo es auch nur noch um 'weiterkommen' oder 'überleben' geht, und nicht darum die intellektuellen Werkzeuge kennen zu lernen um die Welt wie sie ist wirklich zu verstehen. An der Uni setzt sich das dann nur fort. Da ließe sich noch vieles zu sagen, aber das lass ich mal lieber.

Die wenigsten werden Ocaml weiterverwenden können, akademisch interessant mehr nicht. Ich sehe es hier praktisch, wenn ich schon einsteige in diesen Kreis, dann will ich im Zweifel auch Antworten finden, die in der Praxis relevant sind. Javascript und C++ mögen nicht toll sein weder die Sprache noch als Einstieg, aber im Zweifel gibts mind. einen Deppen der vor dem gleichen Problem stand. Davon unterscheiden sich weder Hobby- noch Profi-Programmierer voneinander, programmieren heißt diszipliniert dabei zu bleiben.

Gut, für einen Anfänger mag das richtig sein, aber generell sicherlich nicht. Es geht nicht nur darum bestimmte, verwertbare "Skills" oder wie man heute oft sagt "Kompetenzen" zu erlernen, sondern darum die Zusammenhänge in einem Gegenstandsbereich wirklich zu verstehen. Und da ist es bezüglich Programmierung richtig und wichtig neben den Brot & Butter Sprachen - die man natürlich kennen muss - in solche Exoten wie Ocaml, Haskel, Erlang, Lisp oder auch Assembler einmal tiefer hineingeschaut zu haben. Das hat etwas mit Bildung zu tun und erhöht m.E. auch die Chancen auf dem Arbeitsmarkt, - zumindest auf die interessanteren Jobs. Natürlich wird man sich dann irgendwann spezialisieren und in die Details gehen, aber das passiert im "on job trainig", dafür ist die Uni nicht da..

 

[Athaba]

Exoten sind spannend, funktionale Programmierung sollte man sich anschauen. In den meisten Fällen will man aber nicht unbedingt damit anfangen.

Allerdings gibt es zwei kleine Ausnahmen:
Racket ist echt nett zum Dinge verstehen lernen und sehr integriert, womit man sich die ganzen Mühen spart alles so zu konfigurieren, dass man loslegen kann.
Structure and Interpretation of Computer Programs ist ein extrem gutes Buch für Leute, die in die ganze Materie des Programmierens reinkommen wollen. Nutzt eben LISP.

Aber abseits davon würde ich echt mit was beginnen, was einem bei Laune hält und deshalb ist, auch wenn man von der Sprache halten mag was man will JavaScript ganz interessant. Es gibt Unmengen an Tutorials, man kommt extrem leicht rein, hat ja schon den Browser und kann alles übers Programmieren, was man so braucht. Ob man mit Erfahrung dann dort bleibt ist natürlich eine andere Sache, aber derzeit sind die Zeiten einfach gut bei der Sprache und sogar Jobs kann man damit leicht angeln. In der Hinsicht hat man mit gehypten Sprachen ja einen Vorteil.

Mit C, Python oder JavaScript wird man wohl wie schon gesagt am Besten fahren. Einfach eine nehmen und loslegen. Übertragen von Wissen geht ja leicht. Mit so kleinen oder ganz neuen oder extrem alten, kaum noch verwendeten Sprachen hat man halt echt das Problem, dass man recht arg stecken bleiben kann.

Leicht OT, aber was Schulen und Unis angeht habt ihr meine vollste Zustimmung. Ich glaube nicht... gerade nicht im Bereich Informatik, dass da was gutes dabei rauskommt. Ich kenne viele Leute, die da bis zum Master und weiter gegangen sind um dann erst im Berufsleben draufgekommen sind, dass das nichts für sie ist bzw. dass sie mitunter recht wenig von dem gelernt haben, was sie brauchen oder außerhalb von Forschung nutzen können. Wobei ich wie der Begriff Forschung da manchmal verwendet wird da teilweise (verschwindend gering, aber trotzdem) recht arg finde, aber habe da kein anderes Gebiet mit dem ich das vergleichen könnte. Ich denke aber, dass es da doch enorme Unterschiede zwischen Unis gibt.

 

[rmoe]

Kurze Anmerkung noch dazu: Einer der Gründe, warum ich Pascal empfehle ist, dass es ebenso wie für Python kostenlose (und freie) recht brauchbare Entwicklungsumgebungen gibt.

Insbesondere Debugger sind oft ein hässliches Thema, einfach weil es keinen gibt für irgendwelche momentan schicken oder neuen Sprachen. Und weil debuggen für Profis unerlässlich und für Anfänger häufig ein wesentlicher Aha Moment ist, bei dem sie so manches begreifen.

Klar, wir erfahreneren harten Jungs mögen meist eher keine IDEs, aber für Anfänger sind sie einfach sehr praktisch und hilfreich.

 

[Jeff]

Zum OP:
Ich finde Lua toll. Das ist minimalistisch, einfach zu erlernen (aber komplex genug um langfristig Spaß zu haben) und es gibt mindestens ein tolles Spieleframework dazu (Löve2D, www.love2d.org ). Ich finde, bei Lua kommt so ein wenig der BASIC-Reiz von früher auf, einfach mal was loszuhacken ohne erst ewig dicke Lehrbücher vollständig verstanden zu haben, wie das ja sonst mittlerweile bei fast allem ist.

 

[Athaba]

Achja, Löve2D. Stimmt, damit habe ich meinen Bruder dazu bekommen programmieren zu lernen. Habe mit ihm gewettet, dass er in drei Tagen ein Spiel machen kann, wenn er es ernsthaft lernt und habe die Wette gewonnen. Ist schon eine ganze Weile her.

 

[ninti]

Achja, Löve2D. Stimmt, damit habe ich meinen Bruder dazu bekommen programmieren zu lernen. Habe mit ihm gewettet, dass er in drei Tagen ein Spiel machen kann, wenn er es ernsthaft lernt und habe die Wette gewonnen. Ist schon eine ganze Weile her.

Das Spiel würde ich zu gerne sehen, bzw. wenigstens ein Screenshot davon.
Bzw. du kannst davon etwas erzählen, denn so für nebenbei, könnte man ja das lernen, um die verstopfte Gehirnwindungen von C loszuwerden.
Wenn es doch soooo einfach ist?

Ich würde dann mein kleines RPG machen, wenn so etwas geht?