Wozu C Programmieren?

Mathwork schrieb:
Hallo!

Ich studiere Wirtschaftsingenieur Elektrotechnik und werde im 2. Semester das Modul "C-Programmieren" haben, wo wir den Umgang mit der Programmiersprache C lernen werden.


Das ist ja auch vernünftig. Schließlich soll eure Zunft ja auch an embedded Mikrokontrollern entwickeln können. Der Elektroingenieur arbeitet nunmal oft hardwarenaher als der Informatiker im Bereich Anwendungssoftware, wo Java in der Praxis angesiedelt ist ..
 
ameisenbaer schrieb:
Schließlich soll eure Zunft ja auch an embedded Mikrokontrollern entwickeln können
es gibt Dinge da wäre C++ sogar besser bei embedded, aber sehr viel schwieriger das korrekt und ressourcenschonend damit zu machen.
die richtige profis können da auch bespiele zu gben.
 
Ob man nun C oder C++ für hardwarenahe Sachen nimmt ist schwierig pauschal zu beantworten. Manchmal wird einem die Entscheidung dahingehend abgenommen, das es für die anvisierte Plattform (noch) gar keinen C++ Compiler gibt. :-)
Oder Du hast zwar einen C++ Compiler , aber der unterstützt nur einen, alten gammligen Standard.

Abseits davon hast Du zwar mit C++ mehr Abstratkionsmöglichkeiten. Gleichzeitig ist C++ als Sprache aber auch sehr viel komplexer als C.
Ich find' da C angenehmer (was man aber auch ne Geschmackssache ist). Ein weiterer Vorteil von C ist, das es sich so als Minimalstandard etabliert hat. Fast jede Programmiersprache hat auch ne C Schnittstelle. Bei C++ wird das dann schon ein wenig holpriger.
 
  • Gefällt mir
Reaktionen: Mathwork
Wie andere schon gesagt haben, ist C in der Embedded Entwicklung immer noch extrem relevant.

Abgesehen davon betrachte C als Vehikel um die Prozessorarchitektur praktisch zu verstehen, auf der Programme laufen müssen. Das hilft auch ungemein um auch in abstrakteren Sprachen einzuschätzen wo sich Komplexität hinter einem Befehl versteckt.

Um vorbereitet zu sein, mit allen möglichen neuen Sprachen klarzukommen, sollte man eigentlich immer eine extrem hardwarenahe Sprache gelernt haben, eine Funktionale und eine Objektorientierte. Denn mit dieser Grundlage hat man dann einen guten Überblick und kann sich viel besser in neue Sprachen und Prinzipien reindenken.

C hat hier gleichzeitig den Vorteil auf allen möglichen Architekturen zu laufen und mehr Praxisrelevant zu sein, als irgendein Assembler-Dialekt.

Genauso gibt es einem einen guten Überblick wie denn eine Toolchain ausführbare Dateien aus deinem Code zusammenbaut, weil man die einzelnen Zwischenschritte leicht sehen und beeinflussen kann.
 
  • Gefällt mir
Reaktionen: Mathwork
Der ganze Embedded-Bereich "spricht" nun mal zu 70-80% C. Eine Hochschule, die einen Ingenieur der Fachrichtung Elektrotechnik ohne Kenntnisse in C ausbildet, sollte verklagt werden :D

Es gibt auch sehr gute Gründe für C++ in Embedded Systems (genauso performant, sehr viele nützliche Features). Aber es dominiert nun mal weiterhin C.
 
  • Gefällt mir
Reaktionen: Mathwork
Ich würde die Fragestellung auf 2 verschiedenen Wegen beantoworten:

C ist die Porgrammiersprache Nr. 1, immernoch :-)
https://www.tiobe.com/tiobe-index/

Wenn man danach fragt, welche Porgrammiersprache für die Lehre sinnvoll ist, wäre vielleicht sogar Pascal eine valide Antwort. Denn eigentlich geht es gar nicht darum eine spezielle Sprache zu lernen. Mir selbst hat es enorm geholfen, daß bei uns im Studium erst BNF durchgenommen wurde, bevor überhaupt eine einzige Zeile Code behandelt wurde. Das Ziel dort war uns "Programmieren" beizubringen und weniger eine spezielle Sprache.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Mathwork
MyPVR schrieb:
Mir selbst hat es enorm geholfen, daß bei uns im Studium erst BNF durchgenommen wurde, bevor überhaupt eine einzige Zeile Code behandelt wurde.
Wobei das Typabhängig ist. Ich fande es immer eingängiger am Quelltext zu arbeiten. Vor allem, da man da auch schnell ausprobieren konnte. Denn Programmierung lernt man vor allem durch das tun (wie bei natürlichen Sprachen ja auch, die man eher dadurch lernt das man sie benutzt) und weniger durch theoretisch irgendwelche Konzepte vorstellen. Ich will das auch gar nicht kleinreden. Theorie gehört mit dazu. Aber nen Studenten ein halbes Jahr lang mit Theorie zu quälen bevor er dann überhaupt mal ne Zeile Code schreibt, da kann ich mir nicht vorstellen das das zielführend ist. :-)
 
naja.. BNF hat mir wenig gebracht und nie mehr gebraucht danach, fand es eher sinnloserer Art.
 
  • Gefällt mir
Reaktionen: KitKat::new()
peter.hahn schrieb:
BNF hat mir wenig gebracht und nie mehr gebraucht danach, fand es eher sinnloserer Art.
Ja. Zum lernen ist es eher nicht so geeignet und zu abstrakt.
Anders sieht es aus, wenn man selbst eine Grammatik entwirft.
Zumal es auch Tools gibt, die einem aus der (E)BNF dann auch gleich automatisiert einen Parser bauen.
 
Mathwork schrieb:
Wie schwer ist es denn, den Umstieg von C auf Java zu finden (sollte man sich Java mal selbst beibringen müssen)?

Der Einstieg ist einfach. Die Syntax sehr ähnlich. Java ist deutlich umfangreicher, aber einzig Objektorientierung ist ein Thema, wo muss man sich neu rein denken muss. Ich würde eher den Weg von C nach Java empfehlen, als umgekehrt.
 
Im Studium wurde bei uns Pascal/Modula verwendet. Dank BNF konnte ich aber in sehr kurzer Zeit C lernen.
 
andy_m4 schrieb:
Zumal es auch Tools gibt, die einem aus der (E)BNF dann auch gleich automatisiert einen Parser bauen.
man kann auch mit java lambda ausdrücke etc. nachbauen^^

rekursion, endrekursion, schleifen, if .. dann hast schonmal das wichtigste
dann listen und bäume
und die operationen darauf, fold, map, filter ..

lisp war ziemlich cool zum lernen (mit dr. racket)
https://racket-lang.org/

ach, das waren noch zeiten :D
 
peter.hahn schrieb:
lisp war ziemlich cool zum lernen (mit dr. racket)
Ja. Lisp und insbesondere Racket Scheme ist schon ne coole Sache.
Inzwischen ist Racket auch meine bevorzugte Programmiersprache geworden weils halt Sachen bietet, die andere Sprachen nicht (oder zumindest nicht in der Form) haben. Man kann es durchaus praktisch verwenden, auch wenn die Auswahl an Bibliotheken bei weitem nicht so groß ist wie bei anderen (etablierteren) Sprachen.

DrRacket ist eine solide IDE. Insbesondere für Neulinge, da sie einfach ist und nicht so überladen. Ich benutze sie aber auch gerne. Klar. Die üblichen IDEs bieten mehr Funktionen und Hilfen und manches fehlt DrRacket dann doch. Allerdings ist es durch QuickScript extrem einfach geworden für DrRacket Plugins zu schreiben und so ein paar Sachen die man braucht zu implementieren.
 
java und c++ können inzw. auch beide lambda

ja die Einfachkeit ist genial.
ich fand auch R ziemlich cool und einfach, als wir in Stochastik mit R immer Übungen machen durften
inzw. alles vergessen leider :/

was cool an scheme war, dass man dann einfach ner Funktion ein emoji als Name geben konnte :D
 
GroMag schrieb:
Don't ride a dead horse.
warum dead?
java kannst echt noch oft gebrauchen.

salesforce baut auch z.B. ziemlich stark auf "java" auf.
wobei ich sonst aber gestehe, dass ich mit java demletzt weniger in kontakt gekommen bin, da sind andere Sprachen in den Fordergrund gerückt.
 
spamarama schrieb:
Gerade im embedded Bereich ist C die Sprache der Wahl, denn da kommt es oft auf jedes Byte an. (Rust wäre besser, aber leider sind Rust binaries aktuell viel zu groß).
Es gibt aber einige Möglichkeiten die Binary größe zu reduzieren, per default sind sie aber tatsächlich sehr groß, das stimmt.

Dafür hast du aber die bekannten Rust Vorteile und kannst wenn doch mal benötigt super simpel c integrieren (sofern du nicht c-makros im Umfang vom Linux Kernel nutzt).
 
  • Gefällt mir
Reaktionen: KitKat::new()
peter.hahn schrieb:
java und c++ können inzw. auch beide lambda
Naja. Das ist ja nicht das Einzige was Funktionale Sprachen ausmachen (wobei Racket ja eine Multiparadigmen-Sprache ist).

Zum Beispiel das Vorzugsverweise mit unveränderlichen "Variablen" (quasi Konstanten; immutable) gearbeitet wird. Das man versucht einen Status und Seiteneffekte zu vermeiden. Das widerspricht ja schon allein der objektorientierten Programmierung, wo ja das Objekt einen Zustand hat.

Außerdem löst man Sachen bevorzugt mit Rekursion. Das bedingt aber auch, das man Tail-Call-Optimization hat, damit man nicht so schnell Stacküberläufe bekommt.
Auch das fehlt Java und C++.

Was bei Racket / Scheme dann noch hinzukommt sind Continuations und (hygienische) Makros. Gerade Racket bringt ein sehr mächtiges Makrosystem mit. Das ist ja auch eines der zentralen Features (Programmable Programming Language).
 
Zurück
Oben