Ist es schädlich, mit BASIC anzufangen? (Diskussion aus "Commodore Rechner auf galaktischer Bildungsmission...")

Wirklich schon so schlimm ? ...

Der Film war übrigens genauso häßlich, wie das "Viech" da. Sowas von völlig am Anliegen der Vorlage vorbei und nur Hack'n'Slay. Da hat der Jackson (Regie) vorher zuviel Doom oder wahlweise Diablo II gespielt.

B2T (back to topic) gibt es auch jede Menge und teils sehr gute Tutorials und "assoziierte" Motivationsgeschichten als Film. Vielleicht nicht alle so, daß sie jüngere Leute ab 10 ansprechen würden, aber manche schon trotzdem SEHR GUT.

https://www.youtube.com/watch?v=Z1Yd7upQsXY

Python Tutorial for Absolute Beginners #1 - What Are Variables?

https://www.youtube.com/watch?v=6avJHaC3C2U

The Art of Code - Dylan Beattie

https://www.youtube.com/watch?…lw0_n6DOsbfpOzz1AT81wzjYV

KIDS Programming Liste als Einstiegspunkte

https://www.youtube.com/watch?v=N775KsWQVkw

HOW TO PROGRAM - Getting Started!

und auch als komplette einkaufbare Kurse

https://code.org/

Man auch z.B. mittlerweile auch komplett mit einer "Engine" anfangen. Die "freie" Unity Engine hat mittlerweile auch Module mit der sich Abläufe und Tastenabfragen und Timerevents steuern lassen. Und das ganz ohne störende Kommandozeiletools wie make ; ist evtl. heute in der Wahrnehmung sowas fortgeschrittenes wie es IDEs mal waren als TurboPascal seinen Siegeszug feierte.

Apropos: Pascal ist als Lehrsprache aktuell völlig unterbewertet - ich vermute mal, daß das komplett von Python ausgestochen wird, aber eigentlich ist es gerade als "Absolute-Beginner" Sprache gar nicht wirklich schlecht - und auch diese Sprache kann Sachen, die in Basic sowas von überhaupt nicht gehen (etwa Mengen), ist extrem strukturiert, kann OOP, wenn man es denn will und ist auch noch schnell in der Ausführung. Außerdem gibt es da immer noch jede Mengen Libraries dafür und auch Unterstützung für moderne Hardware. Und das Beste: Man kann sehr viele von den ganz alten Schulbüchern wieder benutzen, die allerdings oft als Lehrbücher nicht taugen sondern eher als unterrichtsbegleitende Texte - Stichwort Dümmler Verlag.

Für Interessierte ist nämlich DAS ein wesentlicher Faktor: ob es brauchbare Bücher gibt, die man nicht nur als Informatiker lesen will, sondern die auch Jugendliche oder Interessierte abholen. Da ist die Auswahl auf alle Fälle immens viel kleiner als in Zeiten der Homecomputer so von 1980 bis 1996. Dafür gibt es natürlich viele von den alten Büchern heute online; aber als Neueinsteiger will man vermutlich schon erstmal mit einem eigenen neuen Buch anfangen.

Zitat von jdreesen

Und im ernst : BASIC hat, im Jahre 2021, im Unterricht gleich welcher Art nichts verloren. Auch nicht fur Kinder.

Da bin ich ja froh, dass unser BASIC-Lehrbuch schon 2019 erschienen ist.

Auch im Ernst: So kann man das einfach nicht schreiben. BASIC verfügt über eine unglaublich reichhaltige (vielleicht die reichhaltigste!) Dialketvielfalt und Programmierkultur. Außerdem war es ja ganz sicherlich einer der wichtigsten Wegbereiter des Mikrocomputerzeitalters. Allein schon deshalb lohnt es sich die Sprache nicht nur vom Hörensagen zu kennen. In unserem o. g. Buch lehren wir BASIC (für medienhistorisch interessiuerte) auch aus genau diesen Gründen: Um der Programmier-Geschichte (nicht so sehr der Programmiersprachen-Geschichte) möglichst material- und techniknah nachzugehen. Das ist für mich auch ein Aspekt von Preservation: Knowledge Preservation, in der es darum geht, das historische praktische Wissen nachvollziehbar zu halten.

Wie hier im Forum andernorts ja schon angemerkt wurde, verfolge ich das Thema BASIC ab Oktober noch etwas intensiver, um den Spuren dieser Programmierkultur anhand ihrer Produkte (vor allem Veröffentlichungen in Zeitschriften) nachzuspüren. Ich öffne dazu hier wohl auch in Kürze einen Thread und freue mich auf Diskussionen zur Sprache.

µP

Ha, lustig. Ein BASIC Lehrbuch von 2019 - das dürfte echt Seltenheitswert haben. Zumal es ja wahrscheinlich, notgedrungen und dem Erscheinungskontext geschuldet sowie auch der generellen Umgebung (QBasic schon vorhanden, Abtippen von Sourcen schon ein Weilchen nicht mehr nötig (Stichworte github, Internet)), ein wenig anders aussehen dürfte, als fast alle BASIC Bücher der frühen und späten Homecomputer Ära.

Bin ja gespannt, ob es da dann mal wirklich einen allumfassenden Überblick über "alle" BASIC Versionen gibt. Das ist nämlich wahrscheinlich schon allein sehr müsam, insbesondere, wenn man wirklich darauf abhebt, die Unterschiede und v.a. deren Bedeutung fürs "handling" herauszustellen. Von den Source Beispielen ganz zu schweigen.

Ich finde ja auch irgendwie witzig, daß über den Ansatz mit der Betrachtung der Sourcecodes als "Literatur", die Linguisten wieder mit ins Boot kommen, die ja der Turing höchstselbst mal aus dem ganzen Spiel herausgeworfen hat (zumindest aus seiner Arbeitsgruppe in Blechtley). Wahrscheinlich werden die feststellen, daß ganz viele Programmiersprachen sich strukturell gleichen und auch nur ähnliche Konzepte machen / Aussagen haben können, weshalb die Schlußfolgerung sein wird, daß es eigentlich nur 2 bis 4 "echte" Sprachen gibt, wogegen alles andere jeweils gegenseitig auf sich abgebildet werden kann. Was dann wieder die überaus spannende Frage aufwirft, warum es eigentlich überhaupt so unglaublich viele Programmiersprachen gibt - und ob das nicht vielleicht einfach nur was mit dem Ego der jeweiligen Erfinder zu tun hat.

Ein wirklich wesentlicher Punkt der Homecomputer BASICs ist ja auch aber auch völlig unabhängig von der Art der Sprache. Ich meine damit den - wie soll man das sagen (?) - ... "Ermächtigungsaspekt", den die einfach dadurch haben, daß sie das primäre Userinterface sind. Was dann einen gewissen Prozentsatz von Leuten gewissermaßen "organisch" dazu einlädt, dem Angebot zu folgen und die Macht am Rechner höchstselbst zu übernehmen. Das ist nämlich ein Punkt, der heutigen Rechnern tatsächlich komplett fehlt. Und auch, oben ist das schonmal angeklungen, vorher oder für professionelle Sprachen wie Pascal (USCD) fehlte.

Vielleicht kann man aus den Erkenntnissen ja auch mal ableiten, was die minimalen Strukturen für eine derartige "Computerfunktionalität" heute sein müßte und wie sie aussehen müßte, damit die Leute sie auch benutzen können und wollen. Die Shell der Unixe untendrunter (auf den Handys) ist es ja anscheinend nicht geworden.

Inhaltsverzsichnis fürs Buch aus dem großen Netz der Netze

inhalt-buch2-medientechnikwissen.pdf

Interessant ist auch die Auswahl der vier Sprachen.

Und was sicherlich eine sehr spannende Sache werden wird, sind die wirklich "coolen" BASIC Programme, weil die ja ganz oft für die schnellen Schleifen Assembleranteile enthalten, was dann wieder sehr maschinenspezifisch wird. Auf dem Archie war das für Games z.B. teils sehr üblich, aber auch für Sachen wie GameOfLive oder Fractale. Das dürfte dann eine "Betrachtung" deutlich erschweren.

Sowas gibt es in der Form auf großen Maschinen wahrscheinlich gar nicht, dafür dort aber eben gleich als gemischte Sprachen, die dann als Objektcode gelinkt werden. Bei Pascal war das mit den Assemblereinschüben zumindest auf den DOS Rechnern durchaus auch oft zu sehen.

ThoralfAsmussen

> Interessant ist auch die Auswahl der vier Sprachen

Die Auswahl halte ich erstmal für recht geradeaus. Auf BASIC käme ich nicht, und hätte dafür eine objektorientierte und eine funktionale Sprache erwartet.

Ich hätte also sowas erwartet:

1. Assembler

2. C

3. Ruby oder Python

4. Erlang/Elixir

Vielleicht noch einen Exkurs nach Lisp oder Smalltalk80.

Was ist Deine Erwartung gewesen?

Also Turbo PASCAL war in den 80er und 90er Jahre auch *sehr* verbreitet und trotzdem wird das nicht so gefeiert bzw. hervorgehoben. Jede Zeit hat wohl seine Stars, BASIC bis zum Ende der Homecomputer-Ära war wohl auch so ein Star. Strukturiertes Programmieren haben aber die wenigsten damit erlernt, von objektorientierter Programmierung ganz zu schweigen.

Ich würde also BASIC nicht schlecht machen, aber es ist halt absolut nicht mehr zeitgemäß.

Da sehe ich Rust, Kotlin und Ruby, vielleicht auch noch Java und Javascript ganz vorne. C und C++ hat für maschinennahe Software natürlich auch noch seine Berechtigung, wenn es auch nicht wirklich geeignet ist, Programmieren zu lernen.

Zum Kennenlernen statt zum ernsthaften Lernen ist aber BASIC vielleicht auch noch ok...

Zitat von Microprofessor

Wie hier im Forum andernorts ja schon angemerkt wurde, verfolge ich das Thema BASIC ab Oktober noch etwas intensiver, um den Spuren dieser Programmierkultur anhand ihrer Produkte (vor allem Veröffentlichungen in Zeitschriften) nachzuspüren.

Das wird sicher interessant! Allein die Unzahl an Dialekten zusammen mit den unterschiedlich vorgebildeten Programmierern könnte spannend werden. Vielleicht zeigen sich da EInflüsse je nach dem, ob es sich um eine billige oder teure Plattform handelt, ob die Programmierer auch mit anderen Sprachen in Kontakt gekommen sind (Pascal zum Beispiel), ob sie schon mal eine GUI gesehen haben usw.

Zitat von konnexus

Ich hätte also sowas erwartet:

1. Assembler

2. C

3. Ruby oder Python

4. Erlang/Elixir

Vielleicht noch einen Exkurs nach Lisp oder Smalltalk80.

Was ist Deine Erwartung gewesen?

Alles anzeigen

Na ja, was heißt schon "Erwartung". Das ist ja nunmal das Buch von 'Microprofessor' und Kollegen - da haben die natürlich komplett die freie Auswahl und können reinschreiben, was sie wollen.

Man muß natürlich vielleicht dazu wissen, daß sie an der HU tatsächlich richtig "echte" Kurse in Basic und Assembler für Medienwissenschaftler angeboten und durchgeführt haben. Wie weit das ging, weiß ich natürlich nicht, aber es ging wohl schon darum die Leute aus dem Studiengang - und das sind vmtl großteils Leute, die über alles nicht übermäßig viel mit "Technik" Kontakt hatten, sonst würde sie ja nicht "was mit Medien" studieren - zu befähigen, Basic und Assembler wirklich mal selbst benutzen zu können und auch aktiv für irgendwelchen kleineren Sachen anwenden zu können. Zumindest hat er hier mal nach Simons BASIC gesucht und wohl auch einige Module gefunden, BBC Basic war auch mal Thema und eben Assembler. Das erkärt dann natürlich zwangsläufig, warum die beiden Sachen da auftauchen - weil man sich da schonmal eingelesen hat und es eben mittlerweile auch kann.

Das Hauptargument für BASIC ist aber sicherlich, und "die" schauen schon wirklich immer bißchen anders auf "Code" - weshalb es ja auch durchaus interessant ist, solche Texte auch mal als Nicht-Medien-Theoretiker anzusehen^* - was schonmal per se zu einer anderen Auswahl von Programmen führt, als sie ein z.B. Physiker aussuchen würde, daß die BASIC Source Codes, um die es hier gehen soll, einfach zu einem großen Teil schlicht in gedruckter Form (also als "Literatur") vorhanden sind. Sei es nun in der 64er oder der ComputeMit, einem Spectrum Magazin oder der HC Homecomputer Zeitschrift. Daneben findet man ja durchaus Einiges noch im Netz, was Leute so mal selbst getippt haben.

Python finde ich eine wirklich gute Wahl, weil das quasi der aktuelle BASIC Nachfolger ist. Zumindest in der Form, wie es als Sprache benutzt wird.

Und es ist sicherlich auch schön, weil, wenn man dann mal diese eigenartige formale Form der Sprachbewertung fertig hat, man auch da jede Menge Source frei verfügbar und für sowas nutzbar finden kann.

Was man/ich evtl. noch erwartet hätte, um Deine Frage zu beantworten, und aus einer historischen Perspektive, wären mindestens auch interessant

Logo (weil es tatsächlich eine Art konstruierte Einsteigersprache ist, die wohl auch wirklich super genau dafür funktionert)

Forth (wegen der völlig anderen Art, wie man "notiert" und wegen dem extensiven Stack-Konzept, was in anderen Sprachen zunehmend aus dem Fokus rückt; und auch, weil die anscheinend oft benutzt worden ist, aber eben eher nicht im Hobbybereich, weshalb "echter" Source Code schwierig ist)

Pascal/Modula2 (weil es i.P. "Sprache" konsequent durchstrukturiert und als "Lern"sprache vorschlägt, inkl. solchen schönen Sachen wie Mengen; vieles davon findet sich dann in den späteren BASICs wieder) - man kann sich hier aber durchaus auch auf den Standpunkt stellen, daß C ja sowieso eine Übermenge von Pascal ist, weshalb das mit C bereits abgedeckt ist. Würde aber für Basic eigentlich auch gelten, nur daß das eben schlicht auch die ältere Sprache ist, was wieder ein Punkt für sie ist

und

mindestens eine von den eigenartigen Sprache aus der ersten KI Hochzeit, was ziemlich mit der Homecomputer-Ära zusammenfällt
(interessanterweise(!)), also Prolog oder Lisp z.B.

dazu wenigstens noch ein Beispiel aus dem Skriptsprachen Universum (sh, csh, rexx, perl, obey-script).

Aber letztlich geht es ja auch gar nicht um einen "Sprachüberblick", sondern um die "Bedienung von Computern auf Programmierebene" und da sind Assembler, Basic, C und Python so schlecht nicht.

Aus einer "echten" Informatik Perspektive spielt sowas ja wahrscheinlich sowieso nicht so die Rolle, was man ja schön auch an den vielen Büchern mit immer gleichen Titeln : "Algorithmen und Datenstrukturen" sehen kann, die es ja in immer wieder gleicher Form für verschiedenste Sprachen gibt, bei eigentlich gleichem Inhalt.

^* kann in dem Zusammenhang mal das Buch von Claus Pias über Computerspiele empfehlen. Ist ein wenig langatmig, aber schon sehr interessant, auch für Leute wie hier, die ja wohl alle wissen, was Defender of the Crown und Rogue ist.

und weil es gerade schön hier reinpaßt, ich das neulich (vorige Woche) mal irgendwo erwähnt aber den Link nicht parat hatte, und es jetzt wieder aufgetaucht ist, hier der schöne Vortrag zu Logo

https://www.youtube.com/watch?v=2ErKLFZJcmg

Turtle Forward 2017. Programmieren für Kinder leicht gemacht - YouTube

Danke für's Teilen Deiner Gedanken, ThoralfAsmussen

In den 80er hatte BASIC halt einige Vorteile:

- Es ist eine Interpretersprache. Man kann direkt Befehle eintippen und ausführen. Ähnlich wie eine Shell oder Kommandozeile heute.

- Befehle, wie load, run, new, save..., würden aus heutiger Sicht eher zum Betriebssystem gehören, sind aber trotzdem BASIC-Befehle

- Wird eine Zeilennummer vor dem Befehl eingegeben, ist es ein Programmbefehl.

- Die "Kommandozeile" ist gleichzeitig der Programmeditor

- Alles passt in ein 8k oder 16k ROM und ist deshalb sofort beim Einschalten da.

Das kann man sich zum Spaß heute nochmal anschauen, aber ich würde heute niemand empfehlen, BASIC zu lernen. Schon gar nicht als erste Programmiersprache, um das Programmieren zu lernen.

Zitat von flowerking

Das kann man sich zum Spaß heute nochmal anschauen, aber ich würde heute niemand empfehlen, BASIC zu lernen. Schon gar nicht als erste Programmiersprache, um das Programmieren zu lernen.

Ich vielleicht schon, denn das Grundprinzip hat sich nicht verändert, Befehle machen was, Befehle stehen hintereinander (untereinander!), Sprungbefehle, Wenn-Dann, Schleifen hat sich ja im Prinzip bis Heute nicht verändert. Bei Basic hat man leicht zu verstehende Schlüsselwörter für die Befehle, und man kann direkt ausführen ohne erst das Kompilieren zu "erlernen" oder abzuwarten, man muss nicht erst etwas "includen" was man noch nicht verstehen kann, usw. Das halte ich für einen Einstieg für nicht verkehrt.

Ich finde Basic gut für einen einfachen Einstieg - das Grundprinzip des Programmierens ist damit ja problemlos zu erlernen.

Dann C nebenher für was Zeitaktuelles und Grundlagen Assembler, damit man besser versteht, warum das C-Programm abkackt.

Mit den Grundlagen versteht man dann auch so industriellen Kram wie Codesys etc...

Ich denke, heute sollte niemand mehr C lernen müssen, und schon gar nicht zum Einstieg. Wenn man wirklich wissen will, wie eine Maschine funktioniert, dann ist Assembler der Weg. Wenn es um Prinzipien der Programmierung geht, gibt es jede Menge High-Level-Sprachen, mit denen sie besser erlernt werden können und bei denen man sich nicht mit Pointern, Include-Files und halbarschigen Makros herumärgern muss. C war vor 40 Jahren vielleicht gerade so akzeptabel, aber heutzutage gibt es jede Menge Programmiersprachen, bei denen man seine Zeit beim Lernen nicht in einem antiken Debug-Umfeld und mit dem Suchen von Segmentation Violations vergeuden muss.

Es gibt ja immer viele verschiedene Wege, etwas zu erlernen, aber ich glaube trotzdem, dass C heutzutage veraltet ist und wenig Raum dafür gibt, höherwertige Abstraktionen und ihre Verwendung kennenzulernen. Auf längere Sicht kommt man natürlich nicht umhin, C-Headerfiles und Datentypen zu kennen, aber dazu muss man sich nicht damit abquälen, selbst etwas in C zu schreiben.

Zitat von hans

Ich denke, heute sollte niemand mehr C lernen müssen, und schon gar nicht zum Einstieg. Wenn man wirklich wissen will, wie eine Maschine funktioniert, dann ist Assembler der Weg. Wenn es um Prinzipien der Programmierung geht, gibt es jede Menge High-Level-Sprachen, mit denen sie besser erlernt werden können und bei denen man sich nicht mit Pointern, Include-Files und halbarschigen Makros herumärgern muss. C war vor 40 Jahren vielleicht gerade so akzeptabel, aber heutzutage gibt es jede Menge Programmiersprachen, bei denen man seine Zeit beim Lernen nicht in einem antiken Debug-Umfeld und mit dem Suchen von Segmentation Violations vergeuden muss.

Es gibt ja immer viele verschiedene Wege, etwas zu erlernen, aber ich glaube trotzdem, dass C heutzutage veraltet ist und wenig Raum dafür gibt, höherwertige Abstraktionen und ihre Verwendung kennenzulernen. Auf längere Sicht kommt man natürlich nicht umhin, C-Headerfiles und Datentypen zu kennen, aber dazu muss man sich nicht damit abquälen, selbst etwas in C zu schreiben.

Bei dem Thema war ich schon mal, es ist wie es ist, ohne C läuft immer noch nichts. Im modernen Frontend ist die Sprache aber tot und das ist auch gut so. Und Assembler anstelle von C, oh je, nichts für mich

Ich betreue immer noch einige C Projekte, im Fahrzeugbereich nutze ich keine dynamische Speicherreservierung, aber Pointer sind meine Freunde. Die ARM Teile laufen 24x7 und dürfen nicht in Fehler laufen, was sie auch nicht machen. Im Monitoring Bereich sind halt viele der Systemcalls für C optimiert. Da nutze ich dann auch dynamische Speicherreservierung. Einen Debugger habe ich aber auch da nie gebraucht.

Ich habe bis vor wenigen Jahren noch einen Hybrid aus C und Java weiter entwickelt. Der Wechsel zwischen den Welten hat Spaß gemacht.

Und, wenn bei uns Azubis neu anfangen dann läuft auch mal für einen Tag ein C64 und es gibt einfache Aufgaben zu lösen, etwas, was in 10-20 Zeilen Basic passt und keine Sprünge wie Goto oder Gosub benutzt. Da taugt Basic allemal.

Zitat von Schroeder

es ist wie es ist, ohne C läuft immer noch nichts

Die Welt ist ja groß, und insbesondere im Embedded-Bereich ist C immer noch sehr verbreitet. Ich denke aber dennoch, das C keine gute Sprache für den Einstieg in die Programmierung ist und es bessere Alternativen gibt - und darum geht es ja in dieser Diskussion.

Abgesehen vom Embedded-Umfeld und bei der Pflege von Legacy-Software im Linux/Unix-Umfeld: Gibt es noch andere Felder, in denen C noch relevant ist?

Zitat von hans

Abgesehen vom Embedded-Umfeld und bei der Pflege von Legacy-Software im Linux/Unix-Umfeld: Gibt es noch andere Felder, in denen C noch relevant ist?

Also, wenn du den Linux-Kernel als "Legacy" bezeichnen willst, ok... Ja, hast recht...

C(++) wird eigentlich in allen Bereichen der systemnahen Programmierung verwendet, wenn es nicht Assembler ist. Und die C-Compiler haben in den letzten Jahren erstaunliche Fortschritte gemacht, und das selbst für uralte CPUs wie Motorola 68000, der Christian Zietz im Atari-Forum.com hat da kürzlich ein eindrucksvolles Beispiel anhand von Coremark gezeigt:

https://www.atari-forum.com/viewtopic.php?t=42161

Zitat

Here is the number of iterations per second, achieved with different compilers. Higher is better:

Code: Select all

Code

Pure C 1.1       :  0.81
vbcc 0.9hp2 (-O3):  1.19
gcc 2.9.5   (-O2):  1.28
gcc 4.6.4   (-O2):  1.72
gcc 8.2.1   (-O2):  1.92
gcc 9.3.1   (-O2):  1.92

Das ist eine glatte Performance-Verdopplung, wie als wenn man den 68000 mit 8 MHz gegen einen mit 16 MHz austauscht, wie ST zu Mega STE. Der Mega STE wird damit etwa so schnell wie der TT. Da braucht man keinen handoptimierten Assembler mehr. Pure-C war in den 1990ern das Ultimaratio der C-Compiler auf dem Atari.

Zitat von hans

Abgesehen vom Embedded-Umfeld und bei der Pflege von Legacy-Software im Linux/Unix-Umfeld: Gibt es noch andere Felder, in denen C noch relevant ist?

In der Entwicklung für macOS und iOS gewinnt zwar Swift immer mehr an Gelände, aber Objective-C ist weiterhin sehr verbreitet und in manchen Anwendungen auch von Vorteil.

Für mich hört sich vieles in diesem Thread ungefähr so an, wie wenn man einem Führerschein-Aspiranten folgendes raten würde:

Zitat

Fang' auf gar keinen Fall mit Rollschuhen (BASIC) an. Du gewöhnst dir Sachen an, die sehr gefährlich sind, wirst irgendwann vom Gaspedal abrutschen wenn du wirklich Auto fährst und wir werden alle sterben.

Fahrräder (C) und Pedelecs (C++) sind vollkommen aus der Mode. Braucht kein Mensch mehr und sind auch nicht geeignet, irgendwas, was man heute braucht, zu lernen. Vergiss das gleich wieder.

Wenn man anfängt, Auto fahren zu wollen, sollte man erstmal lernen, barfuß im Straßenverkehr zu gehen (Assembler). Da lernt man die Grundlagen, auf denen man aufbauen kann.

Bist du dann ein bißchen weiter, dann übe mit einem Trabrenn-Sulky (Ruby). Wenn du das richtig lernst, kannst du später automatisch alles fahren, vom Mofa (Java) über den Gelenkbus (Python) bis zum Kampfpanzer Leopard (Smalltalk).

Außerdem: links abbiegen (Pointer) und Rückwärtsfahren (GOTO) sind verdammt gefährlich. Es gibt neue Autos, die deshalb keinen linken Blinker und keinen Rückwärtsgang haben - nimm so eins, das rettet Leben.

Bei all diesen Fahrzeugen kann man was lernen. Und wenn's nur ist, wie man's besser nicht macht. Anhand nur einer oder zwei Sprachen das Programmieren lernen zu wollen, ist, glaube ich, sowieso nicht besonders zielführend. Während einer beruflichen Laufbahn ändern sich die Säue, die grade durchs Programmiererdorf getrieben werden, sowieso 29-mal, dann ist es besser, möglichst vieles mal gesehen zu haben und verstanden zu haben, was hinter der puren Syntax steckt und der Computer eigentlich tut.

Auch wenn Rollschuhfahren für den Führerschein überhaupt nix bringt, hilft es trotzdem beim strukturierten Denken (wenn das Programm schon nicht strukturiert ist, dann doch wenigstens die Gedanken?) - außerdem macht es Spaß . Ich habe schon BASIC-Programme gesehen, die wesentlich besser strukturiert waren als manche Enterprise-Software..... Soll heißen: Die Sprache ist vollkommen nebensächlich. Am Anfang steht der Hunger, dem Computer beizubiegen, was er machen soll (und den kann man durchaus auch mit BASIC wecken), das andre ist pure Übung - Und das Projekt bestimmt am Schluß die Sprache, nicht etwa deine persönlichen Vorlieben oder was du im Studium gemacht hast. Also schau' dir möglichst viel an, versteh' die Konzepte dahinter und am Schluß kommt es sowieso anders, als du denkst.

Zitat von tofro

Ich habe schon BASIC-Programme gesehen, die wesentlich besser strukturiert waren als manche Enterprise-Software..... Soll heißen: Die Sprache ist vollkommen nebensächlich.

Richtig. Und ehe man das Programmieren lernt, oder zusammen damit, sollte man Algorithmen lernen.

Eigentlich bin ich mehr in .Net unterwegs. Meistens C# oder VB.

Würde eigentlich gerne mal mit C außerhalb von .Net rumspielen. Was würdet ihr da empfehlen?

Naja, Assembler unter Windows dürfte wohl der Overkill sein

Zitat von Elaay

Würde eigentlich gerne mal mit C außerhalb von .Net rumspielen. Was würdet ihr da empfehlen?

Kommt ja sicher bißchen drauf an, wo und mit welchem OS etc. und was gehen können soll.

Zum reinen "Rumbasteln" sehr schön geeignet ist ein (quasi) beliebiges Unix/Linux mit dem allerorten vorhandenen gcc (neudings auch als clang) und dazu eine bunte Bibliothek, damit man auch was zu sehen bekommen kann.

Diese beiden sind da ganz hübsch

Allegro - A game programming library

Allegro Tutorial - Gillius's Programming

https://www.allegro.cc/about , https://github.com/liballeg/allegro_wiki/wiki

und es kommt eigentlich ein Manual mit, was als Übersicht gut taugt, und wo man sich schön durchklickern kann (brauchbar verlinkt innerhalb)

und

Simple DirectMedia Layer - Homepage

SDL2 Game Tutorials - parallelrealities.co.uk

Die SDL hat den großen Vorteil, daß sie quasi für alles "old-school" Geraffel oberhalb von 8Bit vorhanden ist und dort meist auch ganz gute Grafik Performance hat.

Wenn man es moderner braucht, dann ist vmtl. für Grafik Unity einen Versuch wert.

Außerdem brauchst Du sinnvollerweise einen Editor mit SyntaxColouring. Modernere können auch automatisch Sachen zum Tippen vorschlagen (Variabelnnamen etwa), was dann aber schon "spooky" ist.

Notepad++

medit the text editor

Bare Bones Software | BBEdit 14

gibt da ja Einige ...

TextEditors Wiki: HomePage

Mal was zur Beliebtheit und Benutzungsgrad aus offizieller Seite (IEEE), siehe Bildanhang.

"Elixir" hinter "Cobol". Hart.

Zitat von Peter z80.eu

Mal was zur Beliebtheit und Benutzungsgrad aus offizieller Seite (IEEE), siehe Bildanhang.

Interessant, dass HTML und SQL Programmiersprachen sind...

Könnt Ihr das bestätigen, dass noch mehr C als C++ im Einsatz sein soll...?

Zitat von konnexus

"Elixir" hinter "Cobol". Hart.

Elixir (Programmiersprache) – Wikipedia

de.wikipedia.org

Ist mir aber noch nicht in meiner 35-jährigen IT-Laufbahn über den Weg gelaufen...

Zitat von horniger

Könnt Ihr das bestätigen, dass noch mehr C als C++ im Einsatz sein soll...?

Natürlich, wir sehen immer nur die Eisspitze von dem was um uns genutzt wird.

Zitat von Peter z80.eu

Zitat von konnexus

"Elixir" hinter "Cobol". Hart.

https://de.wikipedia.org/wiki/Elixir_(Programmiersprache)

Ist mir aber noch nicht in meiner 35-jährigen IT-Laufbahn über den Weg gelaufen...

Macht nichts, ist ja auch ok so.
Ist halt am Ende Erlang, und das gibt's ja schon seit ein paar Jährchen.

Unser Team hat viel in dieser Sprache geschrieben.
Es ist vorab aufwändiger zu coden, aber der Code ist am Ende wesentlich robuster.

Zitat von Schroeder

Zitat von horniger

Könnt Ihr das bestätigen, dass noch mehr C als C++ im Einsatz sein soll...?

Natürlich, wir sehen immer nur die Eisspitze von dem was um uns genutzt wird.

Bei mir in der Firma sicher 30%-50% C (von 3500 Leut)