Hallo Zusammen Mein Sohnemann möchte den Einstieg in die C-Programmierung wagen. Vorkenntnisse bisher keine! Das ganze schön systematisch mit Lehrbuch und Unterstützung durch Papa :-) Nun stellt sich die Frage welcher Compiler bzw. IDE gut für den Einstieg geeignet ist. Eine schöne aber einfache Entwicklungsumgebung mit Debugger möglichst Freeware (meinetwegen auch mit Einschränkungen) wäre gut. Für den Anfang würden Konsole Anwendungen ausreichen. Ich selbst habe schon mit MS Visual Studio gearbeitet, denke aber dass der Umfang des Pakets einen Einsteiger erschlägt. Ich habe ein wenig über LCC-Win32 gelesen, möchte aber gerne eure Meinung hören.
Also früher habe ich auch mit LCC gearbeitet, der macht schön kleinen Code und ist einfach in der Kommandozeile zu bedienen. Inzwischen bin ich aber exzessiver Nutzer von Dev-C++. Ist ne gut zu bedienende IDE und baut auf GCC auf (MinGW). Damit kann man natürlich auch GUIs erzeugen (Ressource-Files werden auch unterstützt).
Openwatcom ist brauchbar. Allerdings kann man auch eclipse und cdt nehmen, ist etwas moderner von der Aufmachung her.
Rein lerneffekttechnisch würde ich erstmal für Kommandozeile plädieren. Ist nicht modern, aber fördert doch sehr das Verständnis.
Eclipse ist die beste wahl. 1. Free 2. Moderne GUI 3. Unterstützung der Editoren bei der Programmmierung 4. Man gewöhnt sich früh an ein professionelles Arbeiten
Klaus Wachtler schrieb: > Rein lerneffekttechnisch würde ich erstmal für Kommandozeile plädieren. > Ist nicht modern, aber fördert doch sehr das Verständnis. ebenfalls dafür ich würde cygwin als Umgebung vorschlagen(gcc und g++). Notepad++ als Editor. alternativ DevCpp ist die einzige einfache Umgebung. Bei VC++ wird man als Anfänger schon beim Projektanlegen überfordert. Eigentlich braucht man am Anfang nur 2 Funktionen: edit & compile
Wie alt ist denn der Sohn? Kommt er mit englischen Texten zurecht oder sollte es zwingend deutsch sein? Die Frage wie er seinen Einstieg in C gestaltet ist vor allem eine Frage, auf welchem intellektuellen Niveau er (schulisch) sich befindet. Findet er Interesse an mathmatischen Umrechnungen, beispielsweise Dreiecksberechnung, Volumina, generell am Umsetzen mathmatischer Formeln, dann ist er beim Konsolen-C erst mal gut aufgehoben, ihm wird nicht gleich langweilig werden. Texteingabe in der Konsole via scanf und Textausgabe via printf mit seinen vielen Optionen verlocken zum ausprobieren. Dateien lassen sich sehr einfach erzeugen, fortschreiben, wieder öffnen, darin suchen etc. Hat er es nicht so mit der Mathe, weil ihm das zu langweilig ist, dann könnte ihm auch C recht schnell langweilig werden, weil er vielleicht Grafikausgabe als motivierender empfindet?! Dann kommt es drauf an, wie er mit einem C-Dialekt den Zugang zur Erzeugung von Fenstern am besten angeht, die ihm die Ausgabe von Grafik ermöglichen. Möglicherweise überfordert ihn das aber zum Anfang auch und ein BASIC Dialekt, der auch Fenster mit Grafik darin erzeugen kann, wäre für ihn dann die bessere Wahl, für schnelle Erfolge, bevor Frustration entsteht?! Gedruckte Werke zum Programmiereinstieg können vorteilhaft sein, weil man selber abtippen muss und dabei auch Fehler macht (machen darf, machen soll), deren Auswirkungen man erkundet (wichtig!). Alles was Online verfügbar ist (gibt sehr viel Material über C im Netz) verleitet zum 'copy and paste', was zwar der Bequemlichkeit dient, aber dem Lernfortschritt gerade am Anfang eher hinderlich ist. Ob er eine IDE verwendet und wenn ja welche, das würde ich ihm selber überlassen. Den LCC-Win32 kenne ich, habe ihn selber schon verwendet. Seine schwäche ist nach meiner Erfahrung seine Oberfläche, deren Projekterzeugung öfter mal hakelt und wo man auch mal merkwürdige Begleiterscheinungen antrifft. Da ist die IDE von Pelle Orinius besser umgesetzt, viel "smoother", intuitiver siehe http://www.smorgasbordet.com/pellesc/. Für C reicht sowas für den Anfang vollkommen aus. Gibt auch eine deutsche Seite, wo der lcc auch Erwähnung findet unter http://www.pellesc.de/index.php?page=overview&lang=de Worauf ich immer achten würde bei einer IDE ist eine gute Hilfefunktion, möglichst mit Beispielcode. Da war einst die IDE für DOS von Borland namens TurboC einsame Spitze. Am besten ist man fängt einfach mal an. Fahradfahren lernt man einmal im Leben und kann es dann zeitlebens. Programmieren will dauerhaft geübt werden, sonst vergisst man die Syntax und landet bei lägerer Quellcode-Abstinenz schnell wieder beim Hello World ;) Sitzen die Grundlagen aber mal, kann man sich auch als Gelegenheitsprogrammierer immer wieder schnell einarbeiten und hat seine Freude daran die eigenen Kenntnisse wieder aufzufrischen und auszubauen. Nu aber ran! :-)
devc++ da kann man gut mit rumspielen und bekomtm nachdem compilieren eine ausführbare exe damit kann man gut c lernen
>bekomtm nachdem compilieren eine ausführbare exe Das ist hoffentlich bei den anderen Compilern (bzw. Toolchains) auch so... @Informierter Deinen Ausführungen stimme ich grundsätzlich zu. Meiner Meinung nach lässt sich aber auch viel nicht-mathematisches Zeug in der Konsole ausprobieren, wobei logisches Denken natürlich nötig ist. Einfache Spiele wie "4 gewinnt", Mastermind [1] und ähnlich lassen sich z.B. ganz gut im DOS-Fenster spielen, wenn auch graphisch wenig ansprechend. Wer unter Windows programmiert kann mittels API auch etwas Farbe reinbrigen. ;-) Ich habe bei Anfängern und Grafik, v.a. in Sprachen wie Visual Basic wo man die Oberfläche per Drag&Drop zusammenbaut immer etwas Kopfschmerzen: Wichtig am Programmieren sind die Algorithmen, nicht die supertolle Oberfläche. Viele Tools z.B. im Opensource-Bereich haben gar keine eigene Oberfläche, die Programmierer stecken ihre Zeit lieber in das eigentliche Programm. Klaus Wachtler schrieb: > Rein lerneffekttechnisch würde ich erstmal für Kommandozeile plädieren. > Ist nicht modern, aber fördert doch sehr das Verständnis. Dem stimme ich zu. Eine IDE wird schnell zur Blackbox, dabei ist etwas Wissen über die Toolchain von wegen Compiler, Linker usw. durchaus nützlich. Debuggen kann man für den Anfang auch ganz gut mittels printf und getch, da braucht es imho kein großes Programm für. Andererseits kümmert sich so eine IDE um makefile und das ganze Drumherum, das kann einiges an Frust abwenden welcher gerade am Anfang tödlich sein kann. Das alles hängt natürlich von Alter, Kenntnissen und v.a. Motivation des Anfängers ab. [1] http://de.wikipedia.org/wiki/Mastermind
Warum ausgerechnet C? Wäre nicht eine etwas modernere, einfachere Sprache wie z.B. C#/VB.NET sinnvoller? (Nichts gegen C, aber für Einsteiger ist C#/VB denke ich einfacher). Als Entwicklungsumgebung bieten die Express Editionen von VisualStudio alles was man braucht, und das für lau. Du könntest ja z.B. die Toolbar etwas für deinen Sohn "entschlacken".
Wahh, bloss nicht!!!! VB.NET und die dazugehörige IDE sind völlig überladen, keine Chance da durchzublicken. C hingegen hat eine sehr überschaubare Standardbibliothek, da muss man zwar viel selbermachen,lernt aber viel dabei. Und die Tatsache das C auf fast jedem System läuft ist nicht zu unterschätzen... Außerdem konzentriert man sich bei VB mehr auf die Grafik welche am Anfang völlig egal ist. Und von wegen veraltet, C ist noch sehr verbreitet.
Hm, Geschmackssache ;-) Aber wie will man in einer Konsole vernünftig debuggen? Das stell ich mir eher schwierig vor (bzw. kann es mir garnicht vorstellen).
@Rinde
Ganz einfach: printf (ggf. in eine oder mehrere Schleifen verpackt wenns
um Arrays geht), getch bzw. system("pause"), bei vielen Daten auch
fprintf + Logfile.
Für einen Anfänger dürfte das reichen...
Rinde schrieb: > Aber wie will man in einer Konsole vernünftig debuggen? Das stell ich > mir eher schwierig vor (bzw. kann es mir garnicht vorstellen). Noch nie den gdb direkt per command line verwendet? So wie dort hat man das in der command line Ära gemacht. Muss aber heute nicht wirklich sein. Oft hat man freilich auch komplett ohne Debugger entwickelt.
@ R2R (Gast) Die Mathe ist halt ein Beispiel, wo man mal beginnen kann einfache, bekannte Formeln (z.B. die pq-Formel zum Lösen einer quadratischen Gleichung) in einem kleinen C-Programm umsetzen kann. Oder er schreibt sich mal einen kleinen C-Code zur Berechnung einer Parallelschaltung von Widerständen. Kleine Übungen motivieren und erleichtern den Einstieg. Das kann natürlich auch die Umsetzung eines Spiels sein, ich würde mir da aber am ANfang nicht zu viel zumuten. Das ganze soll Spass machen und nicht in Frustration enden. C ist da schon eine schöne bzw. geeignete Basis, aus der man dann auch leicht den Übergang zu C# oder C++ findet. Wir haben damals in der Hochschule mit Pascal angefangen, was auch nicht verkehrt war. Borland hatte ein wunderbares Turbo Pascal 6.0 mit einer sehr guten DOS-IDE und guter F1 Hilfe-Unterstützung. Dazu gab es ein sehr gutes Buch am Markt von Christoph Klawun "Turbo Pascal 6.0, vom Aufsteiger zum Insider" (dicker Wälzer mit rund 800 Seiten). Hat viel Spass gemacht damit Pascal zu vertiefen. Heute ist Pascal gegenüber den C-Dialekten etwas ins Hintertreffen geraten, was wohl auch daran liegt, dass der Übergang zu Windows für C-Sprachen reibungsloser ablief und die heutigen großen Frameworks wie QT mit C++ und nicht Pascal anprogrammiert werden. Aber dennoch gibt es natürlich auch noch sehr aktuelle Pascal-Produkte wie FreePascal, Lazarus und auch Delphi (dem Nachfolger des einstigen Turbo Pascal und dem zeitweiligen Turbo Pascal für Windows 1.0) hat noch seine Anhänger die es gerne nutzen. Rinde (Gast) schrieb: > Aber wie will man in einer Konsole vernünftig debuggen? Das stell ich > mir eher schwierig vor (bzw. kann es mir garnicht vorstellen). Wenn man eine IDE verwendet lassen sich Konsolen-Programme schreiben und auch dann in der IDE debuggen. Die Konsole gibt nur das aus was per printf usw. ausgegeben werden soll. Das Debuggen geschieht in der IDE. Das ist nicht schwer bzw. einfach (siehe Pelles C; geht aber auch in lcc-win32 oder einem der Visual C IDE von Microsoft). gdb würde ich eher unter linux nutzen, für Windows gibt es wie schon erwähnt bequemeres. Es geht auch ganz ohne Debugger, aber für das Verständnis was rund um die Ausführung des eigenen Quellcodes passiert ist der Einsatz eines Debuggers schon recht förderlich. Man kann schön das Programm schrittweise ausführen, sich dabei die Variableninhalte betrachten, schauen was sich jeweils ändert und wie man Speicherinhalte jeweils unterschiedlich interpretieren kann (als 8 oder 16-bit Ganzzahl, als 32-bit Ganzzahl, mit und ohne Vorzeichen, als Fließkommazahl, als String usw.). Für wichtig halte ich da eine intuitive Bedienung, so dass man nicht erst eigens Textkommandos für den Debugger lernen muss, um diesem seine Werte zu entlocken. Muss aber jeder für sich selbst herausfinden, mit was er da besser zurecht kommt oder wo die Vorlieben hinfallen.
> Heute ist Pascal gegenüber den C-Dialekten etwas ins Hintertreffen > geraten, was wohl auch daran liegt .. Hätte noch dazuschreiben sollen, unter den Unix Betriebssystemen bzw. dem späteren Linux war jeher C die Sprache der Wahl (die Quelltexte des OS sind alle in C geschrieben) und der gcc Compiler ist dort fester Bestandteil des OS. Pascal war dort praktisch kein Thema.
>(Nichts gegen C, aber für Einsteiger ist C#/VB denke ich einfacher).
Das sehe ich ein wenig anders: ich würde nicht mit einer OO-Sprache
starten. Da kommt auf den Lernenden zu viel auf einmal zu. Auch wenn mit
dem Aufkommen der OO-Sprachen immer behauptet wurde, Leute mit
prozeduraler Vorbelastung täten sich schwer mit dem Umstieg auf OOP,
konnte ich das nie nachvollziehen.
C halte ich deshalb für gut geeignet, weil sich der Lernende mit den
Basics beschäftigt. Er soll ja ein Gefühl für den Computer auf eher
unterer Ebene bekommen. Darauf aufbauend ist es später sehr viel
einfacher, auch mit IDE zu arbeiten und GUIs zu verstehen. Fängt man
ganz oben an, fehlt IMO einfach das tiefere Verständnis und man , das
die Grundlagen schafft, um höhere Ebenen sehr schnell zu begreifen.
Fängt man auf oberster Ebene an, kann es leicht passieren, dass man
dauerhaft nur kochbuchartig arbeiten kann. Das sehe ich öfter, wenn ich
mit jungen Leute rede, und ich sehe die massiven Defizite durch das
moderne "ich will ganz oben anfangen, Details interessieren mich nicht".
Informierter schrieb: > @ R2R (Gast) > > Die Mathe ist halt ein Beispiel, wo man mal beginnen kann einfache, > bekannte Formeln (z.B. die pq-Formel zum Lösen einer quadratischen > Gleichung) in einem kleinen C-Programm umsetzen kann. Oder er schreibt > sich mal einen kleinen C-Code zur Berechnung einer Parallelschaltung von > Widerständen. Kleine Übungen motivieren und erleichtern den Einstieg. > Das kann natürlich auch die Umsetzung eines Spiels sein, ich würde mir > da aber am ANfang nicht zu viel zumuten. Das ganze soll Spass machen und > nicht in Frustration enden. Ist schon klar, als erstes "Projekt" ist ein Spiel natürlich nicht geeignet (die pq-Formel aber auch nicht...). Es ist allerdings auch nicht soooo kompliziert, meine Version von "4 gewinnt" ist etwas 350 Zeilen lang, davon sind bestimmt 50-100 nur Kommentare, Leerzeilen und Debugcode. Sowas zu programmieren ist z.B. sinnvoll wenn man sich mit 2 dimensionalen Arrays und Schleifen beschäftigen will. A propos debug: Für meine Miniprogramme reichen printf und Co, ein zu guter Debugger ist imho eher kontraproduktiv weil u.U etwas zu viel ausprobiert (und etwas zu wenig nachgedacht) wird... > Fängt man auf oberster Ebene an, kann es leicht passieren, dass man > dauerhaft nur kochbuchartig arbeiten kann. Das sehe ich öfter, wenn ich > mit jungen Leute rede, und ich sehe die massiven Defizite durch das > moderne "ich will ganz oben anfangen, Details interessieren mich nicht". OH JA! **stöhn**
Ach und... Wir diskutieren und diskutieren, aber meldet sich der TO noch mal?
R2R schrieb: > A propos debug: Für meine Miniprogramme reichen printf und Co, ein zu > guter Debugger ist imho eher kontraproduktiv weil u.U etwas zu viel > ausprobiert (und etwas zu wenig nachgedacht) wird... Die Erfahrung hab ich eigentlich auch gemacht. Durch das Debuggen mittels printf muss man sich spätestens dann sehr viel intensiver mit dem Code auseinandersetzen als man das mit einem Debugger müsste. Und sei es nur, um die richtigen Variablen auszuwählen und sich zu überlegen was die Ausgabe bedeutet. Ausserdem hat man mittels printf einen enormen Vorteil: man sieht wie sich Werte im Programmlauf verändern, da man man einen Log mehr oder weniger gratis bekommt.
Das mag oft so sein. Aber bestimmte Fehlerarten, bekommt man mit printf lange nicht so effizient heraus, z.B. in einem größeren Programm wird eine Variable versehentlich durch einen amoklaufenden Zeiger verändert. Als Steigerung schon gesehen: der Zeiger kommt nicht aus dem eigenen Programm, sondern aus einer fremden Lib (die durch falsche Parameter verwirrt wurde). Da bräuchte man viele printf, um das zu finden. Ein Watchpoint macht das schon etwas einfacher.
@Klaus Wachtler Ich denke man muss hier unterscheiden: Geht es um 100 oder 10.000 Zeilen Code? Ist der Programmierer ein Anfänger der sauberes Arbeiten lernen soll oder ein Profi der letzteres hoffentlich kann und effizient (d.h. ohne Zeitverschwendung) verzwickte Fehler finden & beheben muss/will (u.U. in fremdem Code)? Persönlich verpacke ich das ganze Debugzeug immer in #ifdef-Blöcke, so muss man am Ende nicht den kompletten Code manuell "aufräumen" und kann zudem die Debugausgaben schnell wieder anschalten wenn es doch noch Probleme geben sollte. Karl heinz Buchegger schrieb: >Ausserdem hat man mittels printf einen enormen Vorteil: man sieht wie sich >Werte im Programmlauf verändern, da man man einen Log mehr oder weniger >gratis bekommt. Und wenn man den Präprozessor nutzt kann man schnell zwischen Konsole und Datei umschalten:
1 | #define AUSGABE stdout
|
2 | //#define AUSGABE file
|
3 | |
4 | //Je nach Wert von AUSGABE den Code zum Erzeugen der Datei einfügen oder nicht
|
5 | |
6 | fprintf(AUSGABE,"Zeile: %u Variable i: %u\n",__LINE__,i); |
(Vielleicht nicht ganz richtig, meine Kenntnisse sind schon wieder eingerostet...)
R2R schrieb: > Ich denke man muss hier unterscheiden... Eigentlich wollte ich genau das damit sagen :-)
Hallo fragender Gast, die Fragestellung ist schon 5 Jahre her, aber sicher heute noch aktuell. Man bekommt die kostenlose Borland C++ IDE aus dem Internet, z.B. die Version 3.0 und 3.1. Ich habe mit Borland C++ 1.0 angefangen (gibt es noch bei vetusware.com) und nur DOS-Programme geschrieben. Für Anfänger ist es ratsam, Konsolen-Programme zu schreiben, weil dies wesentlich einfacher ist, als sich etwa mit der WIN-API auseinanderzusetzen. Einen kostenlosen C-Compiler (mit C++) gibt es hier http://koti.mbnet.fi/vaultec/mingwstudio.php. Den kann ich empfehlen, ich arbeite gerade damit. Es ist eine integrierte Entwicklungsumgebung, der Editor ist einfacher zu bedienen als der von Borland 3.1-IDE. Ein Handbuch über die GCC-Befehle gibt es hier http://lubo.elsys-bg.org/wp-content/uploads/2009/02/glibc-application.pdf Gruß Thomas
fragender schrieb: > Ich selbst habe schon mit MS Visual Studio gearbeitet, denke aber dass > der Umfang des Pakets einen Einsteiger erschlägt. Ich denke eher dass der Umfang von C (und allem was da an notwendigem Wissen implizit mit dran hängt) den Einsteiger erschlagen oder frustrieren wird. Wie wäre es stattdesen mal einfach mit was gutmütigerem wie Python und IDLE anzufangen? Das ist mindestens genauso relevantes/nützliches/anwendbares Wissen wie C, aber wahrscheinlich um Größenordnungen einfacher zu beherrschen und weniger frustrierend für Anfänger. Du hast ja schließlich auch erstmal mit nem Tretroller angefangen bevor Du irgendwann zum ersten Mal mit nem 200PS Motorrad vorsichtig die ersten Runden auf dem Parkplatz gedreht hast. Ich will damit jetzt nicht alle Scriptsprachen als Tretroller bezeichnen (Das Programmiersprachenuniversum hat mehr als eine Dimension), aber C ist definitiv nicht die Maschine auf die man einen blutigen Anfänger setzen kann der nicht wenigstens schonmal mal weiß wozu Kupplung, Schaltung, Bremse und Gas eigentlich da sind (und wie man die benutzt) damit er sich aufs Wesentliche konzentrieren kann.
R2R schrieb: > Ach und... Wir diskutieren und diskutieren, aber meldet sich der TO noch > mal? Der sucht ein vergessenes Semikolon... MfG Paul
MS Visual Studio Express (kostenlos) bietet die beste Untersützung mit Intellisense und aussagekräftigen Fehlermeldungen.
>Außerdem konzentriert man sich bei VB mehr auf die Grafik
Nö.
VB (bsp VB6) ist für Einstieg besser geeignet als C, weil weniger
kryptisch.
MCUA schrieb: > VB (bsp VB6) ist für Einstieg besser geeignet als C Warum auch immer: das stellst du als Tatsache hin; ich würde es bestenfalls als Meinung bezeichnen.
Aber dass VB weniger kryptisch als C ist, ist wohl eindeutig. Meine Meinung wäre allerdings mit ASM anzufangen.
MCUA schrieb: > Aber dass VB weniger kryptisch als C ist, ist wohl eindeutig. Erstens würde ich das nicht unterschreiben. Nur weil es erstmal lesbarer aussieht, hilft es nicht viel, wenn man nicht genau nachvollziehen kann, was es wirklich macht. Aber egal... Lesbarkeit ist geneu EIN Kriterium. Daraus abzuleiten, daß A besser ist als B, geht nur, wenn man das als eingziges Kriterium sieht. Das ist dann aber subjektiv - darauf wollte ich hinaus.
MCUA schrieb: > Aber dass VB weniger kryptisch als C ist, ist wohl eindeutig. > Meine Meinung wäre allerdings mit ASM anzufangen. VB 6? Auf gar keinen Fall. Zu alt, wird nicht weiterentwickelt, schlechtes Sprachdesign, sehr viel weniger Hilfe im Netz. VB? Nein, lieber C#. Man merkt schon deutlich, dass C# von MS bevorzugt wird. Dazu hat es Operator-Überladung und sogar Zeiger im unsafe Code. ASM? Auch nicht, eventuell später. Am Anfang muss man auch mal schnell zu Ergebnissen kommen, sonst leidet die Motivation. Ganz schlecht für einen blutigen Anfänger, der will sich nicht gleich am Anfang mit technischen Details rumschlagen, der sollte erst mal "Programmieren" lernen. Ich persönlich habe mit C# angefangen, um später bei C und C++ zu landen. Das hat mich vor viel Frust bewart. Das "Programmieren" habe ich schon gelernt gehabt und musste "nur" noch Syntax und Besonderheiten von C lernen. Bei meinen Kommilitonen konnte ich auch sehen, dass C oder C++ keine besonders gute Sprache für den Anfang ist (zu technisch). C#, Python oder auch Pascal ist da besser. C kann man danach noch lernen.
MCUA schrieb: > VB (bsp VB6) ist für Einstieg besser geeignet als C, weil weniger > kryptisch. Beim C-Lernen hilft es hingegen gar nicht. Das ist mit Fremdsprachen anders; wer Italienisch lernt, erlernt auch Grundlagen, die sich auf andere romanische Sprachen anwenden lassen. Im übrigen ist C nicht "kryptisch", schon gar nicht "kryptischer" als diverse Basic-Dialekte, bei denen man teilweise sehr merkwürdige Dinge treiben muss, um Trivialitäten zu erreichen.
Rufus Τ. Firefly schrieb: > Im übrigen ist C nicht "kryptisch", Ganz abgesehen davon, dass die Syntax einer Sprache vielleicht gerade mal 15% dessen ausmacht, was man als Programmierer beherrschen muss.
Man kann in C wunderbar kryptischen Code schreiben, aber das man dazu gezwungen wird, habe ich noch nicht miterlebt. C gibt es genug Möglichkeiten kryptischen Code zu vermeiden. Wer nichts sagende Variablennamen, keine sinnvollen Kommentare schreibt und denkt er müsste so viele In- und Dekrementierungen in eine Zeile reinknallen wie möglich, ist selber schuld. Der schreibt auch in anderen Programmiersprachen keinen besseren Code.
Karl Heinz schrieb: > dass die Syntax einer Sprache vielleicht gerade > mal 15% dessen ausmacht, Wobei es aber schwer fallen kann, mit hässlicher Syntax auf dauer zu leben. Das ist wie mit eiem Auto, das eigentlich noch ganz gut fährt, aber rostig und beulig ist. Aber was ich dich eigentlich fragen wollte: Du hattest ja mal geschrieben, dass Du beruflich an grafischen Oberflächen, also so in der Art von Schaltplan-Editoren arbeitest. Benutzt Du da irgend was in der Art von Debuggern? Ich nicht, ich kann mir auch nicht wiirklich vorstellen, wie das gehen sollte. Aber vorgestern habe ich mal wieder ein paar Stunden mit der Fehlersuche verbracht, weil eine Bounding-Box zu klein war. War letztlich nur eine Zeile, die gelöscht werden musste. Für mich leider 5 Stunden um das zu finden, und entsprechend viel Frust.
Hallo Rinde, Rinde schrieb: > Aber wie will man in einer Konsole vernünftig debuggen? Das stell ich > mir eher schwierig vor (bzw. kann es mir garnicht vorstellen). gdb(1) hat schon Generationen von Entwicklern wertvolle Dienste erwiesen, da gab es noch gar keine grafischen Benutzeroberflächen. Auch heute sind viele GUI-Debugger letztlich nur grafische Frontends für dieses Werkzeug. Und, mit Verlaub: mit .NjET kann man nicht Programmieren lernen. Das ist ein riesiges, proprietäres Framework, welches etliches von der Komplexität, die ein Einsteiger zunvörderst einmal beherrschen lernen muß, in vorgefertigten Bibliotheken mit spärlich dokumentierten Interna verbirgt. Mit sowas könnte aus einem guten Programmierer ein schneller Programmierer werden, aber kein guter Programmierer aus einem Anfänger. Davon abgesehen möchte ich Dich daran erinnern, daß wir hier nicht in einem Windows-, sondern in einem Mikrocontroller-Forum sind. Daher wird es wohl vermutlich das Ziel des OP sein, seinen Sohnemann von vorneherein in ein proprietäres, stark plattformabhängiges und deswegen nur sehr eingeschränkt benutzbares Nischensystem einzusperren. Liebe Grüße, Karl
Karl Käfer schrieb: > Und, mit Verlaub: mit .NjET kann man nicht Programmieren lernen. Das ist > ein riesiges, proprietäres Framework, welches etliches von der > Komplexität, die ein Einsteiger zunvörderst einmal beherrschen lernen > muß, in vorgefertigten Bibliotheken mit spärlich dokumentierten Interna > verbirgt. Mit sowas könnte aus einem guten Programmierer ein schneller > Programmierer werden, aber kein guter Programmierer aus einem Anfänger. Als Anfänger braucht man doch nur System.Console und System.Convert. Da ist nix komplex. Bei C braucht man auch nur printf und co. Karl Käfer schrieb: > Davon abgesehen möchte ich Dich daran erinnern, daß wir hier nicht in > einem Windows-, sondern in einem Mikrocontroller-Forum sind. Daher wird > es wohl vermutlich das Ziel des OP sein, seinen Sohnemann von > vorneherein in ein proprietäres, stark plattformabhängiges und deswegen > nur sehr eingeschränkt benutzbares Nischensystem einzusperren. Die Webseite mag zwar mikrocontroller.net heißen, doch sind wir hier im Unterforum "PC-Programmierung". Also wie kommst du auf µC? C# hab ich damals schon auf Linux verwendet, da funktioniert alles wie es soll. Ausnahme ist GUI, da muss man zu GTK+ greifen. Andernfalls gibt es natürlich auch noch Java.
Meine Güte. Der Sohn möchte nicht C#, Java oder VB lernen. Die Fragestellung ist doch nicht so schwer zu verstehen. Der Beste Vorschlag ist meines erachtens bislang Notepad++ mit Cygwin. Klein, handlich und lenkt nicht ab. Und man lernt zu verstehen was man macht ohne das die IDE alles versteckt.
Rene H. schrieb: > Meine Güte. Der Sohn möchte nicht C#, Java oder VB lernen. Die > Fragestellung ist doch nicht so schwer zu verstehen. Naja eine kleine Empfehlung darf man doch noch abgeben. Wenn jmd. fragt wie man am besten von einer Brücke springen kann, dann sollte man doch wenigstens darauf hinweisen, dass das Springen von Brücken zum Tode führen kann ;). Rene H. schrieb: > Der Beste Vorschlag ist meines erachtens bislang Notepad++ mit Cygwin. > Klein, handlich und lenkt nicht ab. Und man lernt zu verstehen was man > macht ohne das die IDE alles versteckt. Ja das würde ich auch empfehlen. Später sollte er jedoch auch mal eine IDE probieren. Gescheides Code-Complition will ich heute nicht missen. Obwohl es auch Editoren gibt, die das mit Plugins bieten können.
TriHexagon schrieb: > Naja eine kleine Empfehlung darf man doch noch abgeben. Wenn jmd. fragt > wie man am besten von einer Brücke springen kann, dann sollte man doch > wenigstens darauf hinweisen, dass das Springen von Brücken zum Tode > führen kann ;). Darf man sicher. C ist meines erachtens eine sehr gute Grundlage. Weil man lernt das Speicherdenken. Der Speicher wird nicht "versteckt". Zun lernen, führt da Java eher sicher zum Tod (um Deine Analogie zur Brücke zu verwenden).
Rene H. schrieb: > Darf man sicher. C ist meines erachtens eine sehr gute Grundlage. Weil > man lernt das Speicherdenken. Der Speicher wird nicht "versteckt". > Zun lernen, führt da Java eher sicher zum Tod (um Deine Analogie zur > Brücke zu verwenden). Da kann ich dir nur zustimmen. Ich wurde von C# selber etwas "versaut", der Sprung ins kalte Wasser (C auf µC) hat mir gut getan. Allerdings hat der Anfang mit C auch so seine Tücken, welche ich oben angesprochen habe.
Rene H. schrieb: > Meine Güte. Der Sohn möchte nicht C#, Java oder VB lernen. Die > Fragestellung ist doch nicht so schwer zu verstehen. > > Der Beste Vorschlag ist meines erachtens bislang Notepad++ mit Cygwin. > Klein, handlich und lenkt nicht ab. Und man lernt zu verstehen was man > macht ohne das die IDE alles versteckt. Naja. Die Frage wurde vor 5 Jahren gestellt!! Da wird der "Sohnemann" vermutlich längst (s)eine Entscheidung selber getroffen haben und könnte hier ja mal von seinen Erfahrungen ein wenig berichten.
Informierter schrieb: > Rene H. schrieb: > Meine Güte. Der Sohn möchte nicht C#, Java oder VB lernen. Die > Fragestellung ist doch nicht so schwer zu verstehen. > Der Beste Vorschlag ist meines erachtens bislang Notepad++ mit Cygwin. > Klein, handlich und lenkt nicht ab. Und man lernt zu verstehen was man > macht ohne das die IDE alles versteckt. > > Naja. Die Frage wurde vor 5 Jahren gestellt!! Da wird der "Sohnemann" > vermutlich längst (s)eine Entscheidung selber getroffen haben und könnte > hier ja mal von seinen Erfahrungen ein wenig berichten. Oh, das habe ich nicht gesehen. Leichenfledderer :-)
Natürlich ist C "kryptischer" bzw schlechter lesbar als VB.
ua braucht man keine (unnötigen, auch fehleranfällige) {..} keine ';',
kein 'break;'
Wohl Jeder, der noch nie eine Programmiersprache gesehen hat,
wird Basic oder VB oder ähnliches Basic besser/schneller lesen können
als C.
also mit Basic o.ä. bekommt er schneller erste Erfolgserlebnisse.
Das o.g. VB6 ist zwar nicht das neuste, es wird aber 100x mehr können,
als ein Anfänger zunächst benötigt.
MCUA schrieb: > Natürlich ist C "kryptischer" bzw schlechter lesbar als VB. Nö. Sieh Dir nur die verquere "Syntax" beim Aufruf von "Funktionen" oder "Prozeduren" an. Hmm?
Wäre hier nicht ein Sperrkandidat? Die Frage ist fünf Jahre alt und eine weitere Diskussion, welche Programmiersprache die Beste ist, brauchen wir nicht.
MCUA schrieb: > Natürlich ist C "kryptischer" bzw schlechter lesbar als VB. Ich sehe das genau umgekehrt. Zugegeben bin ich gerade die Sprachen gewohnt, die eine C-ähnliche Syntax haben: Also C, C++, Java, C#, ... Visual Basic find ich eher grausam. ;-)
Man schreibt die Function doch nur hin. was soll da verquere sein. >Wohl Jeder, der noch nie eine Programmiersprache gesehen hat, >wird Basic oder VB oder ähnliches Basic besser/schneller lesen können >als C. ich denke, von 100 Befragten Anfängern würden das min 99 sagen
MCUA schrieb: >>Wohl Jeder, der noch nie eine Programmiersprache gesehen hat, >>wird Basic oder VB oder ähnliches Basic besser/schneller lesen können >>als C. > ich denke, von 100 Befragten Anfängern würden das min 99 sagen Super! Kommen da dann auch so lustige Ergebnisse raus, wie die 5-Sterne Bewertungen von Jürgen Wolf und Co.?
Salewski, Stefan schrieb: > Benutzt Du da irgend was in der > Art von Debuggern? Das Hauptproblem ist die meist umfangreiche Datenbasis. In allen meinen Programmen gibt es immer einen Debug Dialog, in dem ich an die Datenbasis ran kann und mir einzelne Dinge im Detail ansehen kann. Das andere oft benutzte Hilfsmittel sind Debug Traces. Die gute alte printf Technik. Debugger natürlich auch. Aber da hat man oft das Problem, dass man meherer Programmläufe mit denselben Daten benötigt und dann wird es lästig im Debugger die immer gleichen Variablen anzusehen, mitzählende Breakpoints zu haben etc. Für mich ist es oft einfacher, einfach ein paar TRACE reinzumachen und dann die Ausgaben zu analysieren bzw. die Veränderung zu sehen. > vorstellen, wie das gehen sollte. Aber vorgestern habe ich mal wieder > ein paar Stunden mit der Fehlersuche verbracht, weil eine Bounding-Box > zu klein war. War letztlich nur eine Zeile, die gelöscht werden musste. > Für mich leider 5 Stunden um das zu finden, und entsprechend viel Frust. gehört dazu, dass man auch mal auf der Leitung sitzt.
MCUA schrieb: > Man schreibt die Function doch nur hin. > was soll da verquere sein. Wie es im jetzigen ist, weiss ich nicht. Aber zumindest bei VB6 wars ja wohl noch so, dass man beim Aufruf einer Funktion die Argumente nicht in Klammern setzte, bei Proceduren aber schon. Oder umgekehrt. (Ist schon lange her) Edit: Ich glaub es war umgekehrt. Proceduren ohne Klammern, Funktionen mit. Es sei denn man rief die 'Subroutine' mittels CALL auf, dann kamen wieder Klammern. Edit2: https://msdn.microsoft.com/en-us/library/office/gg251432.aspx
:
Bearbeitet durch User
Karl H. schrieb: > Das Hauptproblem ist die meist umfangreiche Datenbasis. > In allen meinen Programmen gibt es immer einen Debug Dialog, in dem ich > an die Datenbasis ran kann und mir einzelne Dinge im Detail ansehen > kann. > Ja, so etwas sollte ich in Zukunft wohl auch vorsehen > Das andere oft benutzte Hilfsmittel sind Debug Traces. Die gute alte > printf Technik. > So mache ich das auch. Und meist hat man den Fehler ja schnell gefunden. > Debugger natürlich auch. Aber da hat man oft das Problem, dass man > meherer Programmläufe mit denselben Daten benötigt und dann wird es > lästig im Debugger die immer gleichen Variablen anzusehen, mitzählende > Breakpoints zu haben etc. Für mich ist es oft einfacher, einfach ein > paar TRACE reinzumachen und dann die Ausgaben zu analysieren bzw. die > Veränderung zu sehen. Dann ist für Dich ein Debugger also auch keine Wunderwaffe. Ich höre manchmal von Leuten, die eigentlich permanent nur mit Debuggern arbeiten, selbst bei trivialen Progrämmchen. Und dann fragt man sich natürlich, ob man damit wirklich viel Arbeit bei der Fehlersuche sparen könnte. Aber ich glaube gerade bei wirklich schwierigen Sachen, wie Rekursion, bearbeitung von Baum-Strukturen oder eben auch der Entwicklung grafischer Editoren, ist das Fehlerfinden auch mit Debuggern nicht ganz einfach.
Salewski, Stefan schrieb: > Dann ist für Dich ein Debugger also auch keine Wunderwaffe. Ich benutze ihn gerne. Aber es gibt Dinge, für die ist ein Debugger eher nicht geeignet. Komplexe dynamische Datenstrukturen gehören dazu. Ausserdem bin ich noch von der 'alten Schule'. Ich hab das noch von der Pieke auf gelernt, nur mit printf (bzw. dem Äquivalent in PL/I) zurechtzukommen. Schliesslich liefen die Batch-Jobs auf der IBM für uns Studenten prinzipiell nur in der Nacht :-)
>>>Wohl Jeder, der noch nie eine Programmiersprache gesehen hat, >>>wird Basic oder VB oder ähnliches Basic besser/schneller lesen können >>>als C. >> ich denke, von 100 Befragten Anfängern würden das min 99 sagen >Super! Kommen da dann auch so lustige Ergebnisse raus, wie die 5-Sterne >Bewertungen von Jürgen Wolf und Co.? Ich wollte nicht auf irgentwelche Ergebnisse oä abzielen, sondern nur darauf, dass es im -allgemeinen- besser lesbar ist. >Aber zumindest bei VB6 wars ja wohl noch so, dass man beim Aufruf einer >Funktion die Argumente nicht in Klammern setzte, bei Proceduren aber >schon. Oder umgekehrt. (Ist schon lange her) ja umgekehrt. der Funct-Aufruf wird betr der Args anders geschrieben als ein Sub-Aufruf. (was vor u nachteile haben kann) und? das ist doch Kikifaks gegenüber dem vielen unnützen Zeug in C.
MCUA schrieb: > ja umgekehrt. der Funct-Aufruf wird betr der Args anders geschrieben als > ein Sub-Aufruf. (was vor u nachteile haben kann) und? Kann ich genauso sagen: In C werden viele Sonderzeichen benutzt. Und? > das ist doch Kikifaks gegenüber dem vielen unnützen Zeug in C. :-) In C gibt es kaum 'unnützes Zeug'. Genau das ist ja das 'Problem', dass es eben nicht reicht, nur 80% der Sprache zu kennen. Jedes Zeichen hat seine spezifische Bedeutung und entfaltet des öfteren auch erst im Zusammenspiel mit anderen Zeichen seine volle Power.
MCUA schrieb: >>Wohl Jeder, der noch nie eine Programmiersprache gesehen hat, >>wird Basic oder VB oder ähnliches Basic besser/schneller lesen können >>als C. > ich denke, von 100 Befragten Anfängern würden das min 99 sagen Mag sein. Ist aber trotzdem ein schlechtes Argument. Ich kann auch problemlos Spanisch lesen. Nur verstehe ich kein Wort von dem, was dort steht. So gesehen: ob da jetzt lateinische Buchstaben benutzt werden oder kyrillische, ist für mich Jacke wie Hose. Denn am Ende stehe ich mit dem gleichen Problem da: ich verstehe kein Wort, selbst wenn ich in dem einen Fall die Buchstaben problemloser identifizieren kann.
:
Bearbeitet durch User
ich war mal, vor langer Zeit, in einem "Kurs" als Gast (ein paar Stunden zuschauen) dort hat man zuerst Programmieren gelernt (anhand von UML, Ablaufdiagrammen und vielleicht auch Pseudocode.. weiß ich nicht mehr so genau..) wirklich Programmiert wurde erst nach ein paar Wochen (dann übrigens in Java, ..) anstelle sich also um C oder Pascal zu streiten, oder noch schlimmer "um welchen compiler/ide) vielleicht eher darum ob man nicht zuerst mal Grundlagen lernt (datentypen, operatoren, schleifen, Klassen, vererben, was ist ein compiler/debugger..) und DANN ist man vermutlich schlau genug, um sich SELBER eine Sprache/compiler/ide auszusuchen...
:
Bearbeitet durch User
>Kann ich genauso sagen: >In C werden viele Sonderzeichen benutzt. Und? Viele davon sind unnötig (und viele leute nervt das). zb bei IF.. braucht man definitv keine {.., und ; hinter jedem Befehl braucht man auch nicht.
>Ich kann auch problemlos Spanisch lesen.
kann man aber so nicht vergleichen.
VB und auch C (und auch ASM) basiere gr.teils auf englisch.
MCUA schrieb: >>Kann ich genauso sagen: >>In C werden viele Sonderzeichen benutzt. Und? > Viele davon sind unnötig (und viele leute nervt das). > zb bei IF.. braucht man definitv keine {.., > und ; hinter jedem Befehl braucht man auch nicht. Ui. No further comments. Bis auf einen: Warum fühlen sich eigentlich immer diejenigen dazu berufen, C zu kritisieren, die recht offensichtlich nicht viel Ahnung von C haben? Nicht das es in C nichts zu kritisieren gäbe. Da gibt es so einiges.
:
Bearbeitet durch User
Salewski, Stefan schrieb: > ist das Fehlerfinden auch mit Debuggern nicht ganz einfach. Ein Debugger ist ein nützliches Werkzeug - denken muss man schon noch selbst. Man käme ja auch nicht auf die Idee, dass mit einem guten Compiler das Schreiben von komplexen Programmen ganz einfach wäre. Aber manchmal ist es hilfreich, wenn man die Dinge sehen kann, die beim Programmablauf passieren. Und nicht selten kommt man dann mit einem Debugger schneller ans Ziel als mit printfs. Alleine die Möglichkeit, auf unterschiedliche Bedingungen "scharfstellen" zu können - z.B. auf Änderungen des Speicherinhalts -, ist ein Segen. Allerdings haben auch schon Debugger so viele Features (z.B. Debuggen von Multithread- und Grafikanwendungen, aber auch sehr viele Kleinigkeiten), dass man sich damit ab und zu beschäftigen muss. Ich habe z.B. unter Windows/VS eine ganze Weile meine Debugausgabe-Makros (*) weiter verwendet, bevor ich gemerkt habe, dass man Breakpoints nun ganz einfach in "Debug-Print-Points" umwandeln kann. > Ich höre manchmal von Leuten, die eigentlich permanent nur mit Debuggern > arbeiten Dagegen hilft zumindest teilweise schrittweise Implementierung in Verbindung mit Tests. Zum Thema (der Diskussion, nicht dem des TO von 2010): Als jemand, der in seiner Jugend mit BASIC angefangen hat, würde ich BASIC als Anfängersprache nicht empfehlen - schon gar nicht VB6. Die Syntax ist krude, BASIC verstärkt Anfängerfehler und lädt geradezu zur Produktion von Spaghetticode ein. Außerdem ist es viel zu stark an Windows und das GUI-System gekettet. Wenn man nach Beispielen sucht, findet man zuerst mal alles mögliche über Fenster, Comboboxen, Textboxen etc. pp. Tatsächlich halte ich sogar C# - Konsole, nur mit den nötigsten Teilen des .NET-Frameworks (Eingabe, Ausgabe) und unter Anleitung - für besser geeignet. Dabei fehlt dann aber natürlich das Memory-Management. Damals (tm) an der Uni hat man das Problem übrigens ganz einfach gelöst: Es wurde ein Lisp-Derivat verwendet. So hatten einerseits diejenigen, die schon vorher programmiert haben, keinen "Vorsprung", andererseits wurde das abstrakte, algorithmische Denken gefördert. Für Unfug wie "Anfänger sollten erst einmal Assembler lernen" hatte ich aber ohnehin nie Verständnis. Das ist ja nun genau die falsche Richtung. C, C++, Java, C#, Python usw. bieten einen sinnvollen Mittelweg, wenn es denn eine häufig genutzte Sprache sein soll. (*) die je nach Kontext natürlich dennoch sinnvoll sein können
>>>Kann ich genauso sagen: >>>In C werden viele Sonderzeichen benutzt. Und? >> Viele davon sind unnötig (und viele leute nervt das). >> zb bei IF.. braucht man definitv keine {.., >> und ; hinter jedem Befehl braucht man auch nicht. >Ui. >No further comments. ich kritisiere nicht C an sich, sondern die Syntax! Warum man bei if...els...zif '{'... bräuchte kannst du KEINEM erklären
>BASIC verstärkt Anfängerfehler und lädt geradezu zur Produktion >von Spaghetticode ein. BASIC wurde ja gerade wegen besserer Lesbarkeit "erfunden". Und viele haben ja auch -wegen angebl.. besserer Lesbarkeit- grade deshalb damit angefangen. Und Spaghetticode kann man bei den meisten Sprachen machen, muss es aber nicht. (zudem ist es reine Definitionssache was Sprünge sind und was nicht)
MCUA schrieb: >>>>Kann ich genauso sagen: >>>>In C werden viele Sonderzeichen benutzt. Und? >>> Viele davon sind unnötig (und viele leute nervt das). >>> zb bei IF.. braucht man definitv keine {.., >>> und ; hinter jedem Befehl braucht man auch nicht. >>Ui. >>No further comments. > > ich kritisiere nicht C an sich, sondern die Syntax! > Warum man bei > if...els...zif > '{'... bräuchte kannst du KEINEM erklären richtig. Weil ein 'if' kein '{' verlangt (wie übrigens keines der Compound Statements in C) Lern doch erst mal die Syntax die du kritisierst! Das ist doch lächerlich! AUf diesem Niveau werd ich sicher nicht mit dir über Stärken und Schwächen von C diskutieren.
:
Bearbeitet durch User
Karl H. schrieb: > Lern doch erst mal die Syntax die du kritisierst! Das ist doch > lächerlich! AUf diesem Niveau werd ich sicher nicht mit dir über Stärken > und Schwächen von C diskutieren. Doch - gerade das ist eine echte Stärke von C: Die größten Denkverweigerer bleiben draußen.
Nur erinner sie die drin ständig daran, daß sie doch lieber draußen stehen :-)
Aus meiner Sicht ist die beste Umgebung für einen Anfänger eine Linux-Distribution ohne X-Server. Das GCC-Paket drauf und gut ist. Da hat man dann die komplette Umgebung auf der Maschine. Auch ich habe auf UNIX* Systemen das Programmieren in C gelernt. Eine bessere Umgebung gibt es aus meiner Sicht nicht. Und der VIM lässt sich heute sehr gut bedienen und hat dem vi einiges von der kryptischen Bedienung genommen. Die man-pages gibt inzwischen auch in deutscher Sprache. Also. So what?
OldMan schrieb: > Das GCC-Paket drauf und gut ist. > Da hat man dann die komplette Umgebung auf der Maschine. Hat man da eine selbstinstallierende IDE dabei? Dieses ganze Gefrickel, mit dem ich Linux verbinde, bringt da nichts. (Ich weiß, dass Linux auch 'anders kann', aber bei Entwicklungswerkzeugen und Linux ist meine erste Assoziation: Konsole) Als ich mit C++ angefangen habe, wurde mir überall Borland empfohlen. Allerdings habe ich es gar nicht geschafft, den zum Laufen zu kriegen. Erst als ich aus einem Buch Visual C++ hatte, ging es. Natürlich kommt es auch auf die Vorkenntnisse an. Die waren bei mir praktisch nicht vorhanden, da ich vorher nur auf dem 386er Europaspiel gespielt habe :-)
Hallo, Dussel schrieb: > OldMan schrieb: >> Das GCC-Paket drauf und gut ist. >> Da hat man dann die komplette Umgebung auf der Maschine. > Hat man da eine selbstinstallierende IDE dabei? Mindestens vim und Emacs... Aber ich glaube, für den Anfang genügen auch Kate, Geany, UltraEdit, Notepad++, "Programmers Notepad" (sic!) und jeder andere Editor mit Syntax-Highlighting -- es geht auch ohne, aber das will man . > Dieses ganze Gefrickel, mit dem ich Linux verbinde, bringt da nichts. Von was für einem "Gefrickel" sprichst Du denn? > (Ich weiß, dass Linux auch 'anders kann', aber bei > Entwicklungswerkzeugen und Linux ist meine erste Assoziation: Konsole) Meine auch -- weil eine moderne Shell wie die bash nämlich immer noch eines der leistungsfähigsten und flexibelsten Bedienkonzepte ist, die es gibt. Das haben mittlerweile sogar Microsoft und Apple verstanden (hat lange genug gedauert...) und liefern die Powershell bzw. Bash mit aus, obwohl Microsoft vorher jahrelang versucht hat, die Kommandozeile zu eliminieren und Apple vor MacOS/X erst gar keine hatte. Außerdem ist eine Shell selbst bereits ein Interpreter für ihre eigene Programmiersprache. Programmierkonstrukte wie Variablen, Schleifen und Verzweigungen beherrscht jede moderne Shell, Datei-I/O, einfache Formen der Interprozesskommunikation, und so weiter. Und warum sollte unser Programmiereinsteiger nicht gleich lernen, wie Betriebssysteme mit den Programmen interagieren und kommunizieren? > Als ich mit C++ angefangen habe, wurde mir überall > Borland empfohlen. Allerdings habe ich es gar nicht geschafft, den zum > Laufen zu kriegen. Erst als ich aus einem Buch Visual C++ hatte, ging > es. Also weil Du den Borland-Compiler unter Windows nicht zum Laufen gekriegt hast, ist Linux "Gefrickel"? Das ist mir eindeutig zu hoch. ;-) Liebe Grüße, Karl
Karl Käfer schrieb: > Das haben mittlerweile sogar Microsoft und Apple verstanden (hat > lange genug gedauert...) und liefern die Powershell bzw. Bash mit aus, > obwohl Microsoft vorher jahrelang versucht hat, die Kommandozeile zu > eliminieren und Apple vor MacOS/X erst gar keine hatte. Programmierer die von Mac OS kommen, benutzen auch fleißig die Shell. Da muss man sich nur mal bei Github umsehen. Vim und Emacs sind dort auch bekannt. Keine Ahnung wie man darauf kommt, dass das nur ein Phänomen ist, was es nur unter "rückständigen" Linuxer geben kann und alle anderen verwenden die über alles erhabene GUI. Karl Käfer schrieb: > Außerdem ist eine Shell selbst bereits ein Interpreter für ihre eigene > Programmiersprache. Programmierkonstrukte wie Variablen, Schleifen und > Verzweigungen beherrscht jede moderne Shell, Datei-I/O, einfache Formen > der Interprozesskommunikation, und so weiter. Und warum sollte unser > Programmiereinsteiger nicht gleich lernen, wie Betriebssysteme mit den > Programmen interagieren und kommunizieren? Bei uns war die Unix-Shell Teil der Vorlesungen (Rechnerarchitektur).
Hi TriHexagon, TriHexagon schrieb: > Programmierer die von Mac OS kommen, benutzen auch fleißig die Shell. Naja, seit es eine gibt. Versionen vor X (10) hatten alle keine Shell; aus diesem Grund hatte ich einen Mac als Spielzeug und für richtiges Arbeiten eine Sun Ultra 1. Die habe ich übrigens heute noch. > Vim und Emacs sind dort auch bekannt. Keine Ahnung wie man darauf kommt, > dass das nur ein Phänomen ist, was es nur unter "rückständigen" Linuxer > geben kann und alle anderen verwenden die über alles erhabene GUI. Das "denken" nur eingefleischte Windows-Anwender, die meistens nur die Windows-Shell (command.com bzw. cmd.exe) kennen und die Kommandozeilen deswegen immer noch für völlig rückständiges Zeug halten. Bis dato habe ich auch noch nicht verstanden, warum um alles in der Welt man unbedingt eine IDE benutzen soll. Ich habe einige ausprobiert -- ja, zeitweise sogar Visual Studio zu den seligen Zeiten von NT4 -- aber bis heute habe ich buchstäblich nichts gefunden, das auch nur näherungsweise an einen Emacs heranreicht. > Bei uns war die Unix-Shell Teil der Vorlesungen (Rechnerarchitektur). Aber so ist es eben: was die Einen für rückständiges "Gefrickel" halten, ist für Andere die beste Bedienoberfläche der Welt. ;-) Liebe Grüße, Karl
Karl Käfer schrieb: > Also weil Du den Borland-Compiler unter Windows nicht zum Laufen > gekriegt hast, ist Linux "Gefrickel"? Das ist mir eindeutig zu hoch. ;-) Von Windows habe ich nichts gelesen. Vielleicht hat er Borland unter Linux nicht zum Laufen bekommen. Dann ist Linux natürlich Mist...
>Borland unter Linux
dann simma mal alle froh dass es Borland und auch Kylix nicht mehr gibt,
und konzentrien uns auf aktuelle Tools..
emacs? verdoppelt irgendwie den lernaufwand, zuerst muss man "emacs"
lernen, dann erst die Programmiersprache... machts jetzt irgendwie nicht
leichter..
alles viel zu Old-school, vielleicht sollte man C lernen, wie man heute
alles lernt: per youtube video.. ;-)
:
Bearbeitet durch User
Robert L. schrieb: > alles viel zu Old-school, vielleicht sollte man C lernen, wie man heute > alles lernt: per youtube video.. ;-) nee, das geht heutzutage, indem man sich in einem Forum durchfragt.
Karl Käfer schrieb: > Von was für einem "Gefrickel" sprichst Du denn? Karl Käfer schrieb: > Also weil Du den Borland-Compiler unter Windows nicht zum Laufen > gekriegt hast, ist Linux "Gefrickel"? Das ist mir eindeutig zu hoch. ;-) Wenn ich an gcc ohne IDE und an Linux denke, denke ich an kryptische Konsolenbefehle wie (nur als Beispiel, die richtigen Befehle kenne ich nicht auswendig) PATH=${PATH}:/Developer/Programmieren/Compiler/bin make -c --property=irgendwas Datei.o Datei.c gcc -r -s Datei.o Sowas ähnliches, natürlich mit Windowsbefehlen, hätte ich damals mit dem Borland machen müssen. Und wenn irgendeine Einstellung im System anders waren, funktionierte es nicht mehr. Ich habe es nicht hingekriegt und bin erstmal bei JavaScript geblieben. Erst als dann Visual C++ kam, den man problemlos installieren kann und bei dem man mit etwa zehn Klicks ein Programm erstellen kann, bin ich weitergekommen. Übrigens halte ich HTML und JavaScript für gute Einstiegssprachen. Man braucht nur einen Texteditor und einen Browser und kann in fünf Zeilen sichtbare Ergebnisse erzielen, lernt aber schonmal eine C-ähnliche Syntax kennen. Gerade für Kinder sind die sichtbaren Ergebnisse für die Motivation gut. Ich weiß noch, wie stolz ich war, als ich das erste Mal einen Text in HTML 'programmiert' hatte. Einen Befehl mehr und der wurde sogar in einer anderen Farbe dargestellt. Dann eine Zeile mehr und man konnte schon ein Bild sehen. :-)
was VB betrifft, die Subs kann man auch ganz weglassen, und nur Func
benutzen.
>Lern doch erst mal die Syntax die du kritisierst!
Mir ging es hier nur drum, zu schr dass in diesem Fall das {.. kein
Mensch braucht. das ist definitv so.
zudem, dein bisschen C umfasst max 1% der System-Aspekte.
Nur-Hochsprachen-Schwafler kriegen im Leben kein System ans Laufen weil
sie von drunterliegender Hardware keinen blassen Schimmer haben.
Also laber hier nicht rum.
MCUA schrieb: > was VB betrifft, die Subs kann man auch ganz weglassen, und nur Func > benutzen. > >>Lern doch erst mal die Syntax die du kritisierst! > Mir ging es hier nur drum, zu schr dass in diesem Fall das {.. kein > Mensch braucht. das ist definitv so. Ja ne, is klar
Aus einem anderen Thread, an dem ich zufällig grade drann bin
1 | if( wert ) |
2 | lcd_string( "1" ); |
3 | else
|
4 | lcd_string( "0" ); |
siehst du da irgendwo ein {?
Also ich nicht.
Ist auch nicht weiter verwunderlich. Die Syntax für if lautet in EBNF
Notation
1 | 'if' '(' Expression ')' statement . |
auch da: von einem gefordertem { ist weit und breit nichts zu sehen.
Hmm. Vielleicht doch mal ein bisschen C-Syntax lernen, ehe man sich
darüber mokiert? Dann versteht man auch die Zusammenhänge besser.
:
Bearbeitet durch User
MCUA schrieb: >>siehst du da irgendwo ein {? > Lern erst mal die Syntax Fällt dir da nicht mehr dazu ein? Traurig. Wie wärs wenn du mal darauf eingehen würdest?
Hallo Robert, Robert L. schrieb: > emacs? verdoppelt irgendwie den lernaufwand, zuerst muss man "emacs" > lernen, dann erst die Programmiersprache... machts jetzt irgendwie nicht > leichter.. Das stimmt. Aber wer es einfach haben will, ist beim Stricken vermutlich besser aufgehoben. > alles viel zu Old-school, vielleicht sollte man C lernen, wie man heute > alles lernt: per youtube video.. ;-) Der Punkt ist: die Werkzeuge mögen alt sein und ihre Bedienkonzepte nicht mehr den neuesten Standards entsprechen, aber das macht diese Werkzeuge nicht weniger leistungsfähig und flexibel. Deswegen lohnt es sich immer noch, sich damit zu beschäftigen. Liebe Grüße, Karl
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.