Hey Leute,

ich bin zwar keinb prof. Programmierer, aber habe schon das ein oder
andere "zusammengeschnipselt" was im Geschäft gebraucht wird (ein
Digitales Sprachlabor bestehend aus mehreren Programmen). Dazu benutze
ich VB2005.

Bei meinen µC-Projekten mache ich mich noch unbeliebter. Erstens benutze
ich PICs, zweitens benutze ich dort ebenfalls Basic.

Auf der Technikerschule kommen jetzt AVR und C auf mich zu. Gut, seh ich
mal was anderes.

Was mich jetzt interessieren würde: Warum wird C als Programmiersprache
so vehement als das non plus ultra hochgehalten?

"Früher" konnte man das ja verstehen. Basic war eher ein augebohrter
Script-Interpreter, während C "echte" Programme, bzw eben einfach
Maschinencode der nicht mehr zur Laufzeit interpretiert werden musste.

Aber wie sieht es heute aus?
Ok, lassen wir mal mangels Basic- unterstützung und interesse das
Linux-Lager ausnahmsweise explizit aussen vor.

Wenn ich einen µC programmiere, dann wird ja auf dem nicht Basic
interpretiert, sondern der wandelt meine Basic-Befehle genau wie die
C-Befehle in Maschinencode um.

Was ist hieran schlechter?

Wenn ich einen PC (unter Windows) programmiere, und vb in einer der
.NET-Versionen benutze, dann werden ALLE sprachen in die CLR übersetzt
und interpretiert. Warum sollte C# hier einen Vorteil ggenüber VB haben?

Ich möchte hier nicht C schlecht reden. Mir persönlich gefällt nur die
Syntax von Basic wesentlich besser, da sich einfach mehr an "Sprache"
statt an Kryptische Zeichen gehalten wird.

Wo liegt denn aber in der Zeit nach MS-DOS der große unterschied
zwischen Basic und C, ausser der Syntax?

Ich möchte hier keinen Zigtausendsten Thread C vs Basic lostreten oder
igrendetwas diskreditieren, sondern einfach in Erfahrung bringen ob es
(ausser dem größeren Supportangebot dank größerer Verbreitung)
eigentlich einen wirklichen Vorteil von C gibt (Portierbarkeit
Windows-Linux-Unix mal aussenvor gelassen).

Freue mich auf jede ernst gemeinte, nicht blind zynische Antwort.

greets, Jens

Also ich bin auch damals mit VB angefangen.
Und fand alles schön einfach...

Irgendwann bin ich dann ins Webdesign gekommen und bei php gelandet. -
Wenn du es nicht weißt: PHP hat in seinen Grundzügen zunächst einmal
viel Ähnlichkeit mit C.
Dort zeigen sich die Vorteile:
Wenn man einmal das System verstanden hat, ist der Syntax viel einfacher
und strukturierter als bei Basic.
Und wegen der Objektorientierten Ausrichtung kann wirklich auf
unkomplizierte Weise Probleme lösen.
Das merke ich aktuell, weil ich  mich zwangsweise mit Delphi
beschäftige, da wechseln die Regeln ständig, Fehlermeldungen sind
vorprogrammiert, naja...

Außerdem musst alles als globales System betrachten:
Der PC setzt alles im Assembler um und das wiederum alles in Nullen und
Einsen, das ist zunächst einmal eine erstaunliche Leistung. (Finde ich)
Dieses Übersetzen in Assebmler geht eigentlich am besten mit C, Basic
ist da er unproduktiv, weil mehr Begriff umgesetzt werden, bei C reicht
da die Symbolik für einige begins und ends.
Außerdem ist das Umfeld von C viel grösser, schau dir mal dein
PC-Programm an, das läuft, wenn du glück hast auf deinem PC oder auf
einem oder zwei anderen.
Dem ist mit C nicht so. C hat sich als Standard eingebürgert.

Das heisst nicht, dass ich nicht auch an C verzweifele, auch das
passiert mir gerade, hat zwar mehr mit nem bekloppten Compiler zu tun,
aber das gehört nicht hierher.

C ist einfach der defacto standard. daraus resultiert dass es eine
riesige codebase in C gibt, desweiteren sind für (fast) alle plattformen
sehr performante compiler zu haben. es hat sich im lauf der jahrzehnte
gut entwickelt, bewährt und ist quasi "frei".
daraus folgt dass sehr viele leute C "können" - ich kann zb kein basic.
darum solltest du dich lieber fragen warum kein C ;)

Ich hab mit Pascal angefangen, zu Zeiten als Basic eine rein
interpretierte Sprache war. Meine ersten µC Programme hab ich auch mit
pascal für den 8051er gemacht.... Anfangs hatte ich auch Probleme, die
"Sprache Pascal" gegen "C Code" einzutauschen, ist aber gewöhnungssache.
Ärgern muss man sich mit Compiler mal...
Für jede Anwendung gibts die richtigen Sprachen, warum für Controller
gerade C?
C hat sich etabliert, zu so gut wie jedem Prozessor gibt's einen C
Compiler. Womöglich haben einfach viele Entwickler alles andere auch in
C gecoded, dann halt auch den µC. C hat sehr wenige "echte" Befehle,
diese sind in ANSI C festgelegt, da ändert sich quasi nichts mehr. Viel
Funktionalität (zB printf...) ist in Libraries gepackt. C hat keine
"Dialekte", die's ja in manchen anderen Sprachen gibt (Pascal, Basic
fallen mir spontan ein). Bei anderen Sprachen steht man abseits des
Standard PC oftmals an. Viele Hersteller haben auch in den Datasheets C
und ASM Beispiele angeführt, die man dann in seine eigene Sprache
portieren müsste. Viele Bibliotheken für Controller sind in C
geschrieben. Zu guter letzt bin ich immer wieder beeindruckt, wieviele
Architekturen GCC unterstützt.
Auch wenn Code, den man für Controller schreibt nicht ohne Änderung auf
eine andere Plattform portiert werden kann, so kann man doch sicher sein
einen C Compiler für Contoller XY zu bekommen. Also kann ich mit C
(fast) jede Architektur programmieren, zu der ich einen Compiler
bekommen kann.

Meines Erachtens hat sich der Aufwand C zu lernen für mich gelohnt.
...ich muss ja nicht alles in C Coden    ;)

Warum C? Das erkennst du wenn du es kannst.
Warum eine dynamische Sprache {Python,Ruby,Perl}?
Nachdem man statisch verseucht ist, erkennt man es auch
erst wenn man es kann.
Warum eine funktionale Sprache {CLisp,Haskell}?
... Auch das versteht man erst wenn man es kann ...

Lange Rede kurzer Sinn, du musst es dir neutral
und unvoreingenommen anschauen .. und später
darüber Reflektieren, was dir die neue Sprache
an neuen Konzepten gebracht hat.

grüsse. daniel

> Was mich jetzt interessieren würde: Warum wird C als
> Programmiersprache so vehement als das non plus ultra hochgehalten?

Ich würde C nicht als das Non-Plus-Ultra, sondern eher als den besten
Kompromiss für viele Anwendungsfälle betrachten und glaube, dass die
meisten C-Programmierer ebenso denken.

> "Früher" konnte man das ja verstehen. Basic war eher ein augebohrter
> Script-Interpreter, während C "echte" Programme, bzw eben einfach
> Maschinencode der nicht mehr zur Laufzeit interpretiert werden
> musste.

Und genau in dieser Zeit sind viele Programmierer, die mit Basic
aufgewachsen sind, auf die damals neue und sehr coole Sprache C
umgestiegen.

> Aber wie sieht es heute aus?

Die Programmierer, die damals Basic den Rücken gekehrt oder gar nie
mit Basic angefangen haben, sind gößtenteils heute noch aktiv.

> Ok, lassen wir mal mangels Basic- unterstützung und interesse das
> Linux-Lager ausnahmsweise explizit aussen vor.

Basic unter Linux gibt es, sogar mehrere Systeme. Ich würde aber
behaupten, dass für jeden Rechner, für den es Basic gibt, auch ein
C-Compiler verfügbar ist, aber nicht umgekehrt. Insbesondere bei neuen
Prozessoren wird anfangs meist nur die Programmierung in C oder
Assembler angeboten. In C kann praktisch jeder Rechner programmiert
werden, angefangen vom 1€-Mikrocontroller bis hin zum hunderte
Millionen Euro teuren Supercomputer.

C ist unter den Programmiersprachen in etwa das, was Englisch unter
den natürlichen Sprachen ist. Auch wenn Englisch sicher nicht die
schönste Sprache ist, tut man gut daran, sie zu lernen.

> Wenn ich einen µC programmiere, dann wird ja auf dem nicht Basic
> interpretiert, sondern der wandelt meine Basic-Befehle genau wie die
> C-Befehle in Maschinencode um.

Die Basic-Compiler sind im Laufe der Zeit besser geworden. Aber die
C-Compiler waren eben auch früher schon gut. Wer zuerst kommt, mahlt
zuerst.

> Mir persönlich gefällt nur die Syntax von Basic wesentlich besser,
> da sich einfach mehr an "Sprache" statt an Kryptische Zeichen
> gehalten wird.

Warum programmierst du dann nicht in Cobol? Die Basic-Programmzeile

LET RESULT = FACTOR1 * FACTOR2

ist doch für einen Außenstehenden ziemlich kryptisch. Was soll bspw.
dieser Stern in der Mitte? Geht es hier etwa um astronomische
Berechnungen? In Cobol würde man statt dessen schreiben

MULTYPLY FACTOR1 BY FACTOR2 GIVING RESULT.

So sieht ein ordentlicher Satz aus, den auch ein Nichtprogrammierer
versteht. Sogar der Punkt am Satzende fehlt nicht. Für einen
Cobol-Programmierer sind deswegen deine Basic-Programme genauso
kryptisch wie für dich die C-Programme. Cobol hat sich trotzdem nicht
durchgesetzt. Warum sollte es Basic anders ergehen?

Auch mathematische Formeln mögen kryptisch aussehen. Würde ein
Mathematiker deswegen auf die Idee kommen, komplexe Zusammenhänge
komplett in Prosa zu beschreiben?

> Ich möchte ... einfach in Erfahrung bringen ob es ... eigentlich
> einen wirklichen Vorteil von C gibt (Portierbarkeit
> Windows-Linux-Unix mal aussenvor gelassen).

Die Portierbarkeit ist aber gerade ein wesentlicher Punkt. Reiner
C-Code, der keine Spezialbibliotheken nutzt, ist dank des
ISO-Sprachstandards, den die Compilerhersteller im Wesentlichen auch
umsetzen, auf unterschiedlichen Systemen ohne große Änderungen
komilierbar. Für Basic gibt es zwar ebenfalls einen ISO-Standard. Den
haben aber sicher die meisten Hersteller noch nie zu Gesicht bekommen.
Das Ergebnis: Hunderte verschiedener Basic-Dialekte:

  http://de.wikipedia.org/wiki/Liste_der_BASIC-Dialekte

Außerdem: C ist nun einmal - aus welchen Gründen auch immer - weiter
verbreitet als Basic. Selbst wenn Basic gegenüber C keinen einzigen
technischen Nachteil hätte: Um die Masse der C-Programmierer dazu zu
bewegen, auch Basic umzusteigen, müsste es nicht nur gleich gut sein,
sondern gegenüber C massive Vorteile aufweisen können. Aber was sind
diese Vorteile, außer der (aber auch nur für manche) etwas netteren
Syntax?

Es gibt mittlerweile tatsächlich einige neuere Programmiersprachen,
die mit C in einigen Anwendungsfeldern konkurrieren können. Dazu
zählen bspw. die so genannten VHLLs (Very High Level Languages) wie
Python oder Ruby, deren Ziel es ist, die Softwareentwicklungszeit auf
Kosten des Rechenzeit- und Speicherverbrauchs zu reduzieren. Da aber
bei mikrocontrollerbasierten Großserienprodukten die Entwicklungszeit
meist weniger schwer wiegt als der Ressourcenverbrauch im fertigen
System, werden C und Assembler noch lange die Sprachen der Wahl für
solche Systeme bleiben.

Aber Daniel hat schon recht: Lern C, Python, Lisp und Haskell und mach
dir anschließend selbst ein Bild. Zum Glück sind Programmiersprachen
im Vergleich zu natürlichen Sprachen relativ schnell gelernt.

Die Syntax und die Funktionsvielfalt sind in c einfach besser. Man kann
das z.b. sehr schön an der Parametrierung der "for" Schleifen oder bei
den cast- Operatoren (hat basic jetzt bestimmt auch) sehen. Die
Konstrukte sind ausgereifter/kompakter und flexibler einsetzbar.

wenn ich mal doof fragen darf (ich mein das jetzt Ernst!) woher rührt
eigentlich der Name dieser Programmiersprache? ich meine "visual Basic"
ergibt ja noch einen Sinn wenn man darüber nachdenkt was man damit
macht, aber wie ist man auf "C" gekommen? hat das eine Bedeutung oder
war der dritte Buchstaben im Alphabet einfach noch frei?


Lustig find ich ja auch Java, Laut Java Lehrbuch (Handbuch der Java
programmierung / Guido Krüger) entstand der Name bei einer Kafferunde -
wär hätte es gedacht ;)

http://de.wikipedia.org/wiki/C_%28Programmiersprac...

yalu wrote:

> Ich würde C nicht als das Non-Plus-Ultra, sondern eher als den besten
> Kompromiss für viele Anwendungsfälle betrachten und glaube, dass die
> meisten C-Programmierer ebenso denken.

Ja, das war auch mein erster Gedanke, als ich die ersten Zeilen des
Ursprungsartikels gelesen habe.

BASIC war auch nie eine wirklich schöne Sprache.  Pascal war und ist
eine recht schön aufgebaute Sprache, bestens geeignet für ihren
ursprünglichen Zweck: das Erlernen der Programmierung.  Für mehr als
das war sie in der Ursprungsform nicht unbedingt zu gebrauchen, aber
wer damit programmieren gelernt hat, hat kein Problem, sich danach
in einer anderen (prozeduralen) Sprache auszudrücken.

Ein wesentlicher Vorteil von C ist die insgesamt recht gute
Standardisierung.  Man muss nicht unbedingt eine neue Sprache lernen,
wenn man vom Compiler des Herstellers A auf den des Herstellers B
umsteigen muss.

Man kann übrigens in jeder Programmiersprache unleserlichen
Kauderwelsch verfassen (“Real programmers can write FORTRAN programs
in any language.” :-).  Manche Sprachen wie C oder Perl machen einem
dies zugegebenermaßen einfacher als andere wie Pascal, aber man kann
auch in C lesbare Programme schreiben, wenn man das will -- um so mehr
mit heutigen Compilern, bei denen man nicht gedanklich ,,voroptimieren''
muss, da deren Optimierer gut genug sind, auch etwas ausführlicher
aufgeschriebenen Code in identischen Maschinencode im Vergleich zu
irgendeinem kryptischen Buchstabensalat zu compilieren.

Hallo,

ich möchte hier mal eine Lanze für Basic brechen. Ich verdiene meinen
Lebensunterhalt mit Programmentwicklung für die Druckindustrie
(Betriebsdatenerfassung, Prozessanalyse, Datenbank- und
Warenwirtschaftssysteme, Bildarchive, Bildverarbeitung ...)

Ich bin vor Jahren auf RealBasic (www.realbasic.com) gestossen und
seitdem dabei geblieben. RealBasic ist eine objektorientierte
Basic-Version, die es für Windows, Mac OSX und Linux in jeweils
identischen Versionen gibt. Die IDE enthält einen Cross-Compiler, der es
gestattet, unter jedem genannten OS auch für die jeweils anderen OS zu
compilieren. Es entstehen "einteilige" EXE- bzw. APP-Dateien, man
benötigt keine zusätzliche RuntimeLib oder externe DLLs. Die erstellten
Programme müssen nicht "installiert" werden, kopieren genügt, laufen
auch von CD oder USB-Stick. Man kann Programme mit GUI oder auch
Konsolenprogramme erstellen, auch Dienste und Bildschirmschoner ...

Das klingt jetzt nach Werbung - ist aber ohne Hintergedanken, ich habe
mit dem Hersteller sonst nix zu schaffen. Es gab bisher keine
Aufgabenstellung, die daran gescheitert wäre, weil ich Basic verwende.
Bis hin zu Multimedia-, Netzwerk- oder Datenbank-Themen - es geht flink
und komfortabel.

Mein bisher größtes Projekt war eine komplette Online-BDE (Personal-,
Maschinendaten-, Zeit- und Leistungserfassung) für eine Großbuchbinderei
mit Oracle-Anbindung und zahlreichen Management- und Analysetools. Dabei
sind ca. 40 Touchscreen-Terminals mit Barcodereader an den
Arbeitsplätzen in 2 Werkhallen aufgestellt, an denen ca. 250 Angestellte
Tag für Tag ihre Arbeitsleistung erfassen. Die Daten werden gesammelt,
sortiert und an ein Warenwirtschaftssystem übergeben. Zusätzlich werden
6 Netzwerkdrucker bedient, an denen die Mitarbeiter bei Schichtende
einen Beleg/Tageszettel erhalten. Alles mit RealBasic gemacht ...

Ich glaube, es kommt heute vor allem auf eine vernünftige
Programmstruktur, auf das funktionierende Grundkonzept an, kaum noch
darauf, mit welchem Werkzeug man das dann umsetzt.

Frank

Also C kann man ja nicht mit c# vergleichen. Für C gibt es keine
umsetzung auf CLR.

Ob man nun in C# oder VB.NET programmiert ist egal, der ergebniss ist
wirklich gleich. Es gibt sogar programme die Versuchen aus C# VB.NET
code zu machen, was für den eigentlichen Code auch jetzt gut geht aber
bei schlüsselwörtern versagt.

Zu C. Bei C muss man wissen was man macht. Man kann ich C bei einem
array mit 10 Elementen auf das 20. zugreiffen und da geht meist auch.
(ausser das BS hat was dagegen). Andere sprachen pürfen vorher den
Zugriff und werfen eine exception, aber die Prüfung kostet zeit - darum
ist die C geschwindigkeit höher.

Bei C/C++ kann man mit einer sprache sich überlegen ob ein Programm sehr
optimiert sein soll oder gut erweiterbar/flexibel. (z.b. Exceptions oder
RTTI weglassen)

Leider muss ich auch sagen das die Optimierung der Compiler schlechter
ist als viele meinen. Ich kann jetzt nur von 6er und 7er MS-compieler
sprechen dort ist die optimierung schlechter geworden. Wenn es wirklich
optimiert sein soll hilft nur ein blick auf dei erzeugten ASM code. Die
compieler schaffen zwar das gesamte programm gleichmässig zu optimieren
aber ebend nicht aus einer speziellen funktion das optimum rauszuhohlen.

Ja, irgendwie gibt es eben kein optimales Werkzeug für alles, sondern
ein der Aufgabe angemessenes Werkzeug. Das kann dann durchaus auch ein
guter Basic-Compiler sein - obwohl ich persönlich Basic nicht wirklich
beherrsche.

Die Cross-Platform-Lösung ist schon ein wichtiges Argument, ebenso das
mit den einteiligen EXE-Dateien. In den Zeiten heutiger Ressourcen ist
statisches Linken eine Tugend, denke ich. In dieser Hinsicht hat mich
auch Profilab (eine graphische Entwicklungsumgebung, für
Meßtechnikanwendungen unter Windows) beindruckt: Der Compiler erstellt
EXE-Dateien, in die die ggf. nötigen I/O-Port-Treiber mit eingelinkt
sind. Diese werden dann je nach Windows-Version beim Programmstart
geladen und ggf. auch automatisch wieder entladen. Alles ohne Neustart.

Hi Leutz,

C is nach Assembler die effektivste Sprache, um eine Idee zu Papier -
auf den Prozessor zu bringen.
C erfüllt die denke ich wichtigsten Anforderungen:
- es ist (relativ) leicht lesbar (gegenüber assembler)
- es kann sehr effektiv in assembler umgesetzt werden

Jede Programmiersprache genügt bestimmten Anforderungen. So ist z.B.
BASIC eine Sprache für "jedermann", da man sie schreiben und lesen kann,
als würde man eine Arbeitsanweisung für jmd. schreiben. Sie ist sehr
einfach, wird aber nur interpretiert, d.h. der Interpreter schaut sich
live alles an und schaut, was er machen muss.

Java ist dazu entwickelt, möglichst überall mit geringer
Fehleranfälligkeit zu laufen. Das wird durch die VirtualMachine
sichergestellt, und Mechanismen wie GarbageCatcher etc. Ich finde, es
wird leider zu viel in Java auf dem PC gemacht, weils grotten-lahm ist
(im Vergleich zu C, aber schneller als BASIC).

C ist sehr gut compilier- und optimierbar, und der Programmierer kann im
gewissen Rahmen selbst entscheiden, wie hardwarenah er programmiert.
Anmerkung: Der Thumb(2) - Befehlssatz (ARM) wurde extra dafür
entwickelt, aus  compilern heraus erstellt zu werden. Und der ARM
compiler macht echt verdammt guten asm-code, wenn man das mal
vergleicht, da kann man selber fast nicht besser programmieren :-)

---
Ich hab von QBASIC zu C gewechselt (vor 10 Jahren?), da mit BASIC zu
langsam wurde. Und das war das beste, was ich gemacht habe!


VG,
/r.

Meiner Meinung nach ist C keine Programmiersprache, sondern eher so eine
Art "Überassembler", und das ist Vorteil und Fluch.

Aber genau das macht ihn für Mikrocontroller so geeignet, mal schnell
ein Assembler-Schnipselchen eingefügt und man spart viel Code.

Ein interessantes Feature bei C sind auch die Makros und Defines, hier
wird Code nicht nur nicht angesprungen sondern auch wirklich nicht
erzeugt.

Codesparen ist auf dem uC immer noch ein Thema, hier geht es um viel
Geld (man beachte Faktoren wie 100'000 für die Industrie, hier wird
pingelig auf den Cent oder noch kleiner geschaut).

Entwicklungskosten fallen nur einmal an, kosten für mehr Speicher bei
jeder hergestellten Baugruppe.

Ein anderes Thema sind Laufzeiten, die unter C nicht nur besser sind,
sondern die man da auch leichter abschätzen kann. Jedoch war dieser
Vorteil früher mal größer.

Ciao an alle C-Gequälten

Hallo,

> Jede Programmiersprache genügt bestimmten Anforderungen. So ist z.B.
> BASIC eine Sprache für "jedermann", da man sie schreiben und lesen kann,
> als würde man eine Arbeitsanweisung für jmd. schreiben. Sie ist sehr
> einfach, wird aber nur interpretiert, d.h. der Interpreter schaut sich
> live alles an und schaut, was er machen muss.


Das stimmt heute so nicht mehr, z.B. RealBasic:

- ist ein Compiler
- ist objektorientiert (Module, Klassen, Methoden, Events)
- man kann div. Laufzeit-Prüfungen abschalten
- bedingtes Compilieren (z.B. abhängig vom Zielsystem)

Ich stimme dir zu, was die große Verbreitung von C betrifft.
Wahrscheinlich gibt es für jeden Chip der auch nur 0 und 1
zusammenzählen kann, einen C-Compiler ...

Frank

C kommt halt direkt nach ASM und erlaubt nicht so viele Fehler, wobei
man da auch einiges Falsch machen kann z.B: if (a = 0x01) etc.

C ist immer noch sehr Hardwarenah und wird um einiges besser assembliert
als andere Sprachen.

C ist verbreitet.

C ist gut lesbar (außer man will es nicht ;) )

Über C findet man viel mehr Literatur

C hat die meisten Free-Compiler

Frank Esselbach wrote:

> - ist ein Compiler
> - ist objektorientiert (Module, Klassen, Methoden, Events)
> - man kann div. Laufzeit-Prüfungen abschalten
> - bedingtes Compilieren (z.B. abhängig vom Zielsystem)

Fragt sich nur, was das Ganze dann noch mit BASIC zu tun hat?  Wie
viel deines Wissens kannst du mitnehmen, wenn du z. B. morgen statt
irgendwelcher PC-Applikationen plötzlich einen Controller mit
Bascom programmieren willst?

PS: und wenn du so einen Scheiß like:
if (!error) STATUS  |=((reg_2 & (STAT1 (B_LOC << 3)) ?STAT1 :0) |
(mr_isr2 & E_LOK) ?STAT2 :0));

siehst, lass dich nicht abschrecken, man kann auch anders in C
programmieren.

KOnz wrote:
> C ist doch auch scheiße Assembler! Assembler Meine Herrschaften, wo ist
> denn das Tempo und die Präzision bei C geblieben!
Assembler hat seine Vorteile, wenn's um zeitkritische Anwendungen geht.
Es ist jedoch sehr Plattformorientiert und kann (fast) nur für eine
Architektur bzw einen Prozessortyp optimal implementiert werden. Eine
Hochsprache hingegen kann einen Algorithmus effizient implementieren,
der dann auf vielen Architekturen gut läuft.
Das Tempo und die "Präzision" was immer Du damit meinst sind bei C auch
sehr gut.

>> - ist ein Compiler
>> - ist objektorientiert (Module, Klassen, Methoden, Events)
>> - man kann div. Laufzeit-Prüfungen abschalten
>> - bedingtes Compilieren (z.B. abhängig vom Zielsystem)
>
> Fragt sich nur, was das Ganze dann noch mit BASIC zu tun hat?  Wie
> viel deines Wissens kannst du mitnehmen, wenn du z. B. morgen statt
> irgendwelcher PC-Applikationen plötzlich einen Controller mit
> Bascom programmieren willst?

Das ist wohl wie mit allen modernen Gebrauchsgegenständen: durch die
permanente Optimierung werden die einander immer ähnlicher. Warum sehen
fast alle Kleinwagen gleich aus? Weil sie im Windkanal optimiert werden.

So ähnlich ist es sicher auch mit Programmiersprachen. Im Laufe der Zeit
zeigen sich eben die Stärken und Schwächen jeder Variante und kluge
Entwickler schauen auch mal über den Gartenzaun. Und ob ich nun einen
bedingt auszuführenden Codeblock mit if_then-end_if oder mit
geschweiften Klammern einfasse, ist sowas von egal ...

Mit Bascom bin ich übrigens sehr schnell zurechtgekommen. Ist halt ein
wenig, als würde man vom Dragster auf ein Cart umsteigen.  Aber hat auch
Räder, Lenkung, Motor ... :-)

Frank

C ist urspruenglich entwickelt worden, um Assembler bei der systemnahen
Programmierung abloesen zu koennen. Das funktioniert in C auch
wunderbar, da man grossen Einfluss auf das tatsaechliche Geschehen hat.
Alleine deswegen kann BASIC keine Alternative zu C darstellen.
Genausowenig aber z.B. Java, das zwar von der Syntax sehr aehnlich zu
C++ ist, aber nicht dessen Moeglichkeiten bietet und sich daher
vornehmlich zur High-Level-Entwicklung anbietet. Frueher war es so, dass
es neben BASIC eigentlich Assembler gab. Wollte man tiefer in das
Geschehen eingreifen, hat man einfach Assembler-Code (oder gleich
Maschinencode!) in den Speicher geschrieben und dann ausgefuehrt. Das
traegt aber zu einer strukturellen Programmierung und zur Wartbarkeit
wenig bei.

C eignet sich gerade wegen seiner Speicherverwaltung gut fuer
Mikrocontroller als Alternative fuer Assembler (wofuer es immer gedacht
war). C eignet sich z.B. eher schlecht wenn Du High-Level programmierst
oder eine richtig umfangreiche Standard-Bibliothek brauchst, da waere
dann Java die bessere Wahl. Standard-Algorithmen und Datenstrukturen wie
Baeume oder sogar nur eine Liste findet man in einer libc nicht.

Ich will es jetzt nicht als Flame verstanden wissen, aber BASIC ist
unter Profis in jeglicher Hinsicht indiskutabel. Aber BASIC war ja nie
wirklich als professionelle Sprache geplant, das deutet ja schon das
"Beginner..." am Anfang an. Ich selber habe meine ersten Gehversuche
auch in BASIC gemacht, damals noch mit Zeilennummern und dem klassischen
Spaghetti-Code.

C kann man uebrigens bis zur Unleserlichkeit obfuscaten, siehe hier:
http://www.de.ioccc.org/main.html

Das ist aber alles nur eine Frage des Stils. Ich glaube mein C-Code
sieht recht sauber aus, man darf sich halt nicht zu sehr in Versuchung
fuehren lassen, was aber leicht geschieht, wenn man die Sprache erst
richtig beherrscht, da man beliebige Ausdruecke in einer Zuweisung
verwenden kann usw.

Ich muss mich auch dem Tonus anschliessen: Eine Sprache fuer alles gibt
es nicht, C dominiert halt bei systemnaher Programmierung (OS, Treiber,
System- und shell), andere Sprachen haben andere Vorzuege. Du hast
eingehend gesagt, die BASIC-Syntax gefaellt Dir besser als jene von C.
Es gibt halt auch keine einheitliche Syntax, da sich keiner an die Norm
haelt. Ich finde die Syntax von BASIC absolut grauenhaft, das hat sich
wieder gezeigt, als ich in die Verlegenheit gekommen bin eine C-Control
damit zu programmieren zu muessen...

Naja Du wirst ja C nun lernen ich denk dann kannste das alles auch
selber nachvollziehen.

Greets,
Michael

>> http://www.de.ioccc.org/main.html
Make my day :D

"C" ist die Abkürzung für "cryptic" :-)

Dann hast du wohl noch nie APL gesehen. Dagegen ist C direkt
geschwätzig.

Ich habe mit APL angefangen:
http://en.wikipedia.org/wiki/APL_(programming_lang...

Andreas Kaiser wrote:
> Dann hast du wohl noch nie APL gesehen. Dagegen ist C direkt
> geschwätzig.

Ha, APL.

Ich hab noch mein APL 'Manual' aus meiner Studienzeit.
Das 'Manual' ist eine Plastikkarte in der Größe einer
Scheckkarte, beidseitig bedruckt.

C, C++, Java, C#, VB usw. ist alles der gleiche Mist. Ob man nun {}
schreibt oder begin/end etc. macht keinen Unterschied.

Die etablierten Sprachen sind allesamt schlechtes Mittelmaß. Nichts
besonderes, voll mit katastrophalen Design-Entscheidungen und Altlasten;
jeder fühlt sich berufen in diesen Sprachen irgendwie, irgendwelche
Programme zusammen zu schustern.

Recht hast du ja. Aber was zu was rätst du statt dessen?

Hi Leute, danke für die vielen Antworten.

APL ist ja mal echt Grausam. Aber genau solche Konstrukte wie
if (!error) STATUS  |=((reg_2 & (STAT1 (B_LOC << 3)) ?STAT1 :0) |
(mr_isr2 & E_LOK) ?STAT2 :0));

sind echt Grausam.

Den Vorteil werd ich ja dann ab September in meinem Kino selbst merken.

Ich habe mich Hauptsächlich gefragt ob es HEUTE denn noch diesen
TECHNISCHEN Totschläger-Punkt gibt. Anscheinend ist aber die
Portierbarkeit der Hauptgrund, bzw einfach die Verbreitung.

Man hat uns mal in der  Berufsschule versucht C++ in der Konsole
beizubringen.
Wir (Elektroniker) konnten damit grad mal garnix anfangen.
Konsole=Langweilig, nix Praxisnahes gemacht, und in 2 Jahren bis zum
Array gekommen. Da war mir die Lust am Programmieren dann erstmal
vergangen. Bin dann eben quasi über VB.Net wieder zum Programmieren
gekommen, bzw habe vorher schon etwas PIC in Assembler rumgespielt (mehr
nicht). Da ja für die 12-18F mittlerweile der wirklich schicke Compiler
von MikroElektronika vorhanden ist, habe ich mich halt für den
entschieden. Wirklich hübsche und funktionelle IDE inbegriffen.

Ich muss aber auch sagen dass ich selbst immernoch Noob genug bin
wirklich alles auszuprobieren und nicht zu Simulieren oder ICD-Debuggen.

Danke auf jeden Fall für eure Mühe!

Grüßle, Jens

Jens Plappert wrote:

> APL ist ja mal echt Grausam.

Für jemanden, der mit mathematischer Ausdrucksweise und insbesondere
linearer Algebra vertraut ist, nicht unbedingt. Den stört dann eher die
unstrukturierte Programmierung mit Neigung zu Spaghetticode.

Andreas Kaiser wrote:
> Recht hast du ja. Aber was zu was rätst du statt dessen?

<nicht ernst gemeint>

Wie wärs mit Prolog?
Ist auch mal was ganz anderes als der übliche Algol-Ableger Kram.

Jens Plappert wrote:

> Ich habe mich Hauptsächlich gefragt ob es HEUTE denn noch diesen
> TECHNISCHEN Totschläger-Punkt gibt.

Genau das ist der springende Punkt.
Alle dies Sprachen gehören im Grunde derselben Sprachfamilie
an und unterscheiden sich nur in Details.
Allerdings sind alle Programmiersprachen immer Turing-komplett.
Sind sie es nicht, dann sind sie im Grunde uninteressant.
Turing-komplett bedeutet: Wenn es überhaupt möglich ist, für
ein Problem ein Programm zu schreiben, dann kann man das mit
dieser Sprachen.

Den Totschlag Punkt gab es nie und wird es auch nie geben.

Die Diskussion über Programmiersprachen ist so sinnvoll, wie
die Fragestellung ob das Rad nun rot oder grün angemalt werden
soll. Für die übliche Funktion, nämlich zu rollen, spielt dieses
Kriterium so gut wie keine Rolle.

Letztendlich ist eine Programmiersprache nur ein Werkzeug. Die
beste Programmiersprache ist immer noch die, die man beherrscht.

Karl heinz Buchegger wrote:

> Wie wärs mit Prolog?
> Ist auch mal was ganz anderes als der übliche Algol-Ableger Kram.

Jo. Das ist ein besonderer Spass. Eine Programmiersprache, die so tut
als ob es dabei keine Abfolge von Abläufen gäbe. Aber wenn man als
Ergebnis mehr haben will als "ja" oder "nein", dann muss man mit einer
Programmiersprache, die keine Abläufe kennt, dann doch wieder
sequentielle Abläufe programmieren. Man muss also wissen, wie das
Programm zur Laufzeit vom Interpreter tatsächlich abgearbeitet wird, um
auf dieser Basis dann den Ablauf zu kontrollieren. Insofern ist die
Sprache Prolog eigentlich ihre eigene Widerlegung und sollte eher
Prounlog heissen.

>Die etablierten Sprachen sind allesamt schlechtes Mittelmaß. Nichts
>besonderes, voll mit katastrophalen Design-Entscheidungen und Altlasten;
>jeder fühlt sich berufen in diesen Sprachen irgendwie, irgendwelche
>Programme zusammen zu schustern.

So schlecht können sie nicht sein. Man ist mit ihnen zum Mond (und
zurück) geflogen, schießt Satelliten in den Orbit, bewältigt die
Globalisierung, unterhält mehrere Millarden Menschen, führt Kriege
(schluck!) und hofft sogar das Überleben der Menschheit auf Dauer zu
gewährleisten.

Geniesser wrote:

> So schlecht können sie nicht sein.

Ja, und es gibt sehr viel mehr Fliegen auf der Erde als Menschen. Aber
das ist für mich kein Grund, deren offensichtlich überaus erfolgreiche
Auswahl an Nahrungsquellen zu teilen.

>Ja, und es gibt sehr viel mehr Fliegen auf der Erde als Menschen. Aber
>das ist für mich kein Grund, deren offensichtlich überaus erfolgreiche
>Auswahl an Nahrungsquellen zu teilen.

Dann mach dich mal auf und schreibe deine all umfassende fehlerfreie
perfekt designte Super-Programming-Language

bin gespannt was bei raus kommt :)

Ada?

Ob Linux Distributionen in Ada besser werden?

Ob Vista in Ada die Welt revolutioniert?

.NET in Ada?

Ist ein Ada Compiler eigentlich in Ada geschrieben?

Gibt es überhaupt fehlerfreie Compiler? Kann es jemals fehlerfreie
Software geben?

Geniesser wrote:
> Ob Linux Distributionen in Ada besser werden?

Ich könnte es mir zumindest sparen einmal in der Woche das System auf
meinem Server zu aktualisieren, weil irgend ein Buffer Overflow oder ein
Integer Underflow in libpng oder libtiff o.ä. die Sicherheit gefährdet.
Schau mal in irgend eine beliebige Security-Mailingliste rein, >90% der
Bugs sind C-typisch. Und komm mir jetzt nicht mit "ein guter
Programmierer kann solche Bugs vermeiden". Nur ein perfekter
Programmierer könnte das, und den gibt es nicht.

>Ich könnte es mir zumindest sparen einmal in der Woche das System auf
>meinem Server zu aktualisieren, ..

ich fürchte nur niemand wird jemals ein Ada-Linux kreieren

>Und komm mir jetzt nicht ..

mach ich schon nich :)

vielleicht auf das von Rufus immer verächtlich genannte dot net Geraffel
umsteigen (falls es da was für Server gibt)? "Managed Code" dürfte doch
Speicherlegs den garaus machen, oder?

> Letztendlich ist eine Programmiersprache nur ein Werkzeug. Die
> beste Programmiersprache ist immer noch die, die man beherrscht.

Ja und nein.

Das Hauptproblem: Die Sprache legt den eigenen "Denk-Horizont" fest. Hat
man nur einen Hammer, ist alles ein Nagel.

Wenn man Leuten erzählt, die seit 10 Jahren in C oder ähnlichen Sprachen
programmieren, es gibt Sprachen, da gibt es keine Variablen, keine
Schleifen, und in diesen Sprachen ist man mit deutlich weniger
Source-Code schneller am Ziel, dann verdrehen diese Leute die Augen und
können sich das überhaupt nicht vorstellen.

Ich kommentiere das einfach mal ganz ungezwungen, ja?

Jens Plappert wrote:
> ich bin zwar keinb prof. Programmierer, aber habe schon das ein oder
> andere "zusammengeschnipselt" was im Geschäft gebraucht wird
Jubb, ich bin ebenfalls Hobbyist (18 Jahre alt), hab aber auch schon die
ein oder andere Prüfroutine für Firmen geschrieben.

> (ein Digitales Sprachlabor bestehend aus mehreren Programmen).
Hui :-)

> Dazu benutze ich VB2005.
Hab dafür noch VB6 benutzt, das war damals noch das neueste.

> Bei meinen µC-Projekten mache ich mich noch unbeliebter. Erstens benutze
> ich PICs, zweitens benutze ich dort ebenfalls Basic.
Basic is doch in Ordnung, wenns dir schnell genuch ist und wenn du die
Maschine (=PIC, AVR oder was auch immer) damit sicher im Griff hast.

> Auf der Technikerschule kommen jetzt AVR und C auf mich zu. Gut, seh ich
> mal was anderes.
Genau...

> Was mich jetzt interessieren würde: Warum wird C als Programmiersprache
> so vehement als das non plus ultra hochgehalten?
Ganz frei aus dem Gedächtnis: Naja, C ist irgendwo steinalt. Basic war
zwar schon früher da, aber C hat meines Wissens nach zum ersten Mal so
richtig den Sprung geschafft, unabhängig von einer Architektur zu sein.
C wurde glaub ich geschaffen, um UNIX-Zeuchs damit zu programmieren, und
UNIX war seinerzeit recht verbreitet auf Großrechnern (wie der
"Nachfolger" Linux es heute ist; damals war Microsoft noch ganz
klein...)

> "Früher" konnte man das ja verstehen. Basic war eher ein augebohrter
> Script-Interpreter, während C "echte" Programme, bzw eben einfach
> Maschinencode der nicht mehr zur Laufzeit interpretiert werden musste.
Jubb, aber Basic konnte man auch recht früh schon kompilieren. Nur
musste für jeden Mist quasi die BASIC-Sprache umgebaut werden, weil
vieles in Basic doch über Sprachkonstrukte realisiert wurde ("OPEN x FOR
INPUT...") und nicht wirklich flexibel war. Man denke nur an diese
Krämpfe für die RS232 (OPEN "COM1:BAUD:PARITY"... oder sowas).
C hatte da was abstraktes zur Hand, was ohne Veränderung der Sprache
selbst leicht auf alles Mögliche ausgedehnt werden konnte.

> Aber wie sieht es heute aus?
Prinzipiell genauso, nur die Kisten wurden flotter :-)

> Ok, lassen wir mal mangels Basic- unterstützung und interesse das
> Linux-Lager ausnahmsweise explizit aussen vor.
Basic geht unter Linux problemlos, so isses net.

> Wenn ich einen µC programmiere, dann wird ja auf dem nicht Basic
> interpretiert, sondern der wandelt meine Basic-Befehle genau wie die
> C-Befehle in Maschinencode um.
I.d.R. ja. BASCOM (das COM steht für Compiler) macht genau das. Es gibt
aber sehr wohl auch BASIC-Interpreter, die in den Prozessor geladen
werden!
Mach dir nur klar: Jeder COMPILER macht prinzipiell nix andres, als aus
einer Hochsprache Assemblercode zu erzeugen. Erst dieser wird dann vom
ASSEMBLER in Maschinencode (11010001 oder so) übersetzt. Durch welchen
Compiler der Assemblercode erzeugt wird, ist also wurscht.

> Was ist hieran schlechter?
Garnix. Was willste denn machen?

> Wenn ich einen PC (unter Windows) programmiere, und vb in einer der
> .NET-Versionen benutze, dann werden ALLE sprachen in die CLR übersetzt
> und interpretiert. Warum sollte C# hier einen Vorteil ggenüber VB haben?
Ganz einfach: Erstens: Gewohnheit. C# ist zwar schon Verhumbugtes C/C++,
aber immer noch eher für C-Programmierer zu benutzen, als Basic.
Und dann, wie oben gesacht: C ist/war deutlich flexibler als Basic,
allein von Seiten der Sprache her. Das VB.Net ist beim besten Willen
kein "Basic" im klassischen Sinne mehr, das is morz-aufgebohrt.
Wirkliche "Vorteile" seh ich ganz persönlich in den Unterschieden von
C#/VB und was .NET noch alles hat, nicht mehr.
Das .NET selbst aber hat letztlich irgendwo die meisten Vorteile
(Unabhängigkeit von Architektur, Managed Code etc.) von JAVA
geklaut...so scheint mir das jedenfalls.

> Ich möchte hier nicht C schlecht reden. Mir persönlich gefällt nur die
> Syntax von Basic wesentlich besser, da sich einfach mehr an "Sprache"
> statt an Kryptische Zeichen gehalten wird.
Jubb, genau deshalb hat man Basic erfunden: Beginner’s All-purpose
Symbolic Instruction Code. Eine Sprache für *Programmieranfänger*!
Andrerseits: Schreib mal paar zehntausen Zeilen Code in Pascal/Delphi.
Da ist mir ein schnelles "{ ... }" jedenfalls lieber als immer
"begin...end" auszuformulieren. Ich will programmieren und keine Romane
schreiben :-)
Das Kryptische übrigens verliert seinen Charakter ganz schnell, wenn man
mal ein erstes C-Programm getippt hat. Letztlich ist C wesentlich
"logischer" aufgebaut, als BASIC, im Sinne von "strikter" und mit
klareren Regeln.

> Wo liegt denn aber in der Zeit nach MS-DOS der große unterschied
> zwischen Basic und C, ausser der Syntax?
Wie gesagt, Gewohnheit, Flexibilität, Übersichtlichkein (i.S.v. strikt
und klar), Portabilität auf Quellcodeebene (C-Programme kann man, wenn
man auf einige Sachen achtet, z.B. 1:1 auf Windoof und Linux
compilieren, auch mit unterschiedlichen Compilern. Bei Basic ist das
schwierig, da die Standards irgendwie...wässrig sind, jeder kocht da
sein eigenes Süppchen.
Außerdem gibbet C-Compiler für (ich behaupte mal) sämtliche
Architekturen.

> Ich möchte hier keinen Zigtausendsten Thread C vs Basic lostreten oder
> igrendetwas diskreditieren, sondern einfach in Erfahrung bringen ob es
> (ausser dem größeren Supportangebot dank größerer Verbreitung)
> eigentlich einen wirklichen Vorteil von C gibt (Portierbarkeit
> Windows-Linux-Unix mal aussenvor gelassen).
Wie gesagt :-)
Riesen-Support ist Gold wert, genauso wie riesen Verbreitung, damit kann
man sich die Zukunft geben. Nenn mir doch mal gescheite Basic-Compiler
mit kompatibler Syntax für Windows. Richtig - Microsoft VB.NET. Sonst
noch was? -- Merkste was? Wenn MS sein Basic einstampft, kannste deine
Programme in die Tonne kloppen.
Für C hingegen kannste Borland, Microsoft, GNU-Gcc (mit oder ohne
Cygwin) und wie sie alle heißen, benutzen.

Hoffe, das hilft dir ein ganz klein bissken -- soweit "meine" Sicht der
Dinge.

Um mal Prolog wieder aufzugreifen. Ich kann kein Prolog,
aber soweit ich die Idee verstanden habe, geht es darum
das Problem deklarativ zu beschreiben und die Engine/Kernel
verschiedene ableitbare Aussagen deduzieren lassen.
Eine einfache Art eines Expertensystem oder einer Modelsimulation.
Modelsimulation deswegen, weil es da auch deklarativ ein
Model nur beschrieben wird, ohne die Lösungsschritte explizit anzugeben.

Ich beschäftige mich gerade mit der Simulationsprache Modelica.
http://www.modelica.org/
Für mich war das interessante (und neue) am Konzept vom Modelica,
dass man anstatt der üblichen Zuweisungen, die Relationen
in Gleichungen ausdrückt. Eine so beschriebene Komponente,
kann je nach dem was als input vorliegt, die Gleichung
in eine Zuweisung überführen.

BTW Hat vielleicht jemand damit gearbeitet?

Danke Sven, für deinen wirklich umfangreichen Post.

Leute, ich muss mal echt loswerden dass es mich wundert wie zivil, ja
geradezu mustergültig dieser Thread trotz "Grundsatzfrage" abläuft.

Ich habe an so etwas hier ehrlich gesagt kaum mehr geglaubt.

DANKE SEHR!

Sven Pauli wrote:

> aber C hat meines Wissens nach zum ersten Mal so
> richtig den Sprung geschafft, unabhängig von einer Architektur zu sein.

Bereits die erste implementierte höhere Programmiersprache, Fortran,
erfüllte diese Bedingung. Eher besser als C. Nur ist Fortran ungefähr 2
Jahrzehnte älter als C. Andere ebenso architekturunabhängige ältere
Sprachen sind beispielsweise das schon erwähnte ungemein geschwätzige
COBOL, das konzeptionell stark abweichende Lisp und das die Grundlagen
der strukturierten Programmierung schaffende Algol.

Das besondere an C war hauptsächlich, dass es im Unterschied zu den
anderen Sprachen mitsamt für Minicomputer geeignetem Betriebssystem an
Universitäten kostenfrei verfügbar war, anfangs mitsamt veröffentlichtem
Quellcode. Und man in C besser Betriebssysteme schreiben konnte als in
den anderen damaligen Sprachen.

Und was man im Studium kennenlernt, verwendet man gern auch später, wenn
es einigermassen passt.

> C wurde glaub ich geschaffen, um UNIX-Zeuchs damit zu programmieren, und
> UNIX war seinerzeit recht verbreitet auf Großrechnern

Genauer gesagt auf Minicomputern. Das waren jene Dinger, die klein genug
waren, dass man ohne grosse Mannschaft damit arbeiten konnte - und weil
vergleichsweise günstig in Anschaffung und Betrieb auch durfte. Auf
Grossrechnern war Unix schlicht nicht existent.

> "Nachfolger" Linux es heute ist; damals war Microsoft noch ganz
> klein...)

Microsoft hatte damals überhaupt noch nicht existiert.

Warum man insbesondere bei Microcontrollern überall C verwendet: Es war
zum richtigen Zeitpunkt da, und es war dafür geeignet.

Die ersten Generationen von Microcomputern wurden wesentlich in
Assembler programmiert. Hochsprachen gab es auch schnell, inklusive dem
erwähnten Fortran, COBOL und sogar einem eingedampften Ableger des
IBM-Monsters PL/I. Bis auf Basic und Turbo Pascal waren die allerdings
meist reichlich teuer, jenseits dessen was man sich leisten wollte oder
konnte. Die wohl einzige Sprache, die Ende der Siebziger auf keinem
einzigen Microcomputer gesichtet werden konnte, war C.

Microcontroller wiederum wurden noch lange Zeit fast ausschliesslich in
Assembler programmiert. Oder in stark in vereinfachten Spezialsprachen,
beispielsweise Intels PL/M.

Wer in den 80ern auf unterer Ebene an Rechnern herumprogrammierte,
eigenen oder den erwähnten Minicomputern, der kam, wenn er Glück hatte,
mit C in Kontakt. Und stellte fest, dass dies damit ganz gut geht. Denn
dafür war es ja gebaut worden.

Als dann Microcontroller soweit waren, in einer höheren Sprache
programmiert zu werden, war C da, die Leute kannten C, und es war dafür
geeignet. Denn die Programmierung von Minicomputern, damaligen PCs und
Betriebssystemen wie dem ursprüngliche Unix unterscheidet sich nicht
stark von der Programmierung heutiger Microcontroller. Was die
Anforderung an die Programmiersprache angeht. Und wie man auch an der
Entwicklungsgeschichte von Linux sieht, waren das Projekte, die
überwiegend von einer einzigen Person gestemmt werden konnten.

PCs wiederum haben sich davon längst wegentwickelt. Sowohl wie
Programmiertechniken wie auch die Komplexität der Interfaces sind längst
auf einem Niveau, auf dem man mit C mehr Unfug anrichtet als nötig.
Soweit man heutige GUIs überhaupt noch darin programmieren kann.

In den 80ern hatte das amerikanische Verteidigungsministerium das
Problem, dass deren diverse Softwareprojekte für Embedded Systems (also
dem Zeug in Raketen, Flugzeugsteuerungen usw) in einem Zoo
unterschiedlicher Programmiersprachen enstanden. Das sollte sich ändern
und die Forderung nach Vereinheitlichung führte zur Entwicklung von Ada,
gewürzt mit der Forderung, dass künftig alle Projekte darin zu
realisieren seinen (keine Ahnung was von dieser Forderung noch übrig
ist). Dabei entstand jedoch eine Sprache, deren anfängliche
Implementierungen und nötigen formellen Zertifizierungen derart komplex
und langsam abliefen, dass kaum jemand ausserhalb dieses Zirkusses das
ernst nahm.

Von der Sache her ist Ada zweifellos besser für Embedded Systems
geeignet als C. Aber der Zug ist längst abgefahren. Man verwendet was
man kennt, was man kriegt, was gut unterstützt ist, kurz: was alle
anderen verwenden. Die Qualität der Programmiersprache selbst ist dabei
nur ein Kriterium unter vielen.

jede programmiersprache hat ihren zweck, sogar perl ;-)

ich habe auch mit basic angefangen zu programmieren - am c64, bin dann
über turbo-basic, vb6 bei c(++), java, assembler, python, (vhdl - ich
weiß, ist keine richtige programmiersprache), c#, ocaml,... gelandet.

was mir (nach c) aufgefallen ist:
kurze "quick and dirty" programme (z.b. 10000 spam-mails vom pop3-server
löschen) oder programme, bei denen es nicht auf die geschwindigkeit
ankommt schreibe ich am liebsten in java.
für meine avrs verwende ich hauptsächlich asm, c muss für systemnahes
"herhalten" - egal ob kommunikation über die rs232, (rt-)kernel-module
oder anderes.
c# und ocaml sind eher "exoten", die ich für die uni verwenden musste,
wobei mir der gui-designer von c# aber nicht schlecht gefällt.

FAZIT:
siehe erste zeile, nur sind eben manche sprachen besser für ein
bestimmtes problem geeignet als andere.
zur ersten frage im thread: ich glaube C konnte sich derartig weit
verbreiten, weil es seit der entstehung quasi mit unix "verheiratet" war
und sich darüber verbreiten konnte - mit allen vor- und nachteilen

C und Konsorten ist Mittelmaß. Die Masse strebt immer zum Mittelmaß.

Und Unbekannte klopfen immer sinnlose Sprüche...  Verallgemeinerungen
sind sowieso immer richtig.  Oder immer falsch? ;-)

der unbekannte verwendet wahrscheinlich INTERCAL
http://de.wikipedia.org/wiki/INTERCAL
oder schreibt einfach 42 unter jede aufgabe, um sie zu lösen ;-)

Unbekannter wrote:

> Die Masse strebt immer zum Mittelmaß.

Und du präsentierst hier nur eine Tautologie. Denn was die Masse
verwendet ist geradezu per Definition das Mittelmass.

Unbekannter, rede doch nicht um den heißen Brei, sondern nenne mal deine
ach so tolle Programmiersprache

wir wollen schließlich alle gern was dazulernen :)