Hi Andreas
Hatte gerade dieses Problem
In einem Source Code, der mit den [ C ] [ /C ] Tags markiert war, kam
die Zeile vor
array[ b ] = ....
Das Abschicken wurde verweigert, mit der Begründung das [ b ] auf Spam
hinweist (natürlich ohne die Leerzeichen zwischn [ ] und b) :-)
Könnte man diese Restriktion zumindest in den [ C ] Sektionen lockern?
Ich kann den Spamfilter gut verstehen. ;-) Bei der Syntax von C kann man nicht nur als Mensch husten und spucken. SCNR Paul
Was soll jetzt an array[i] oder eben array[ b ] so schlimm sein? Dass es nicht temperature_array heißt oder velocity_array oder gaggabanana_array? Und warum [ b ] auf Spam hinweisen soll, erschließt sich mir ehrlich gesagt nicht so richtig - in anderen Foren ist dies das normale Tag für bold, also für Fettdruck.
[i] [ b ] [u] Vermutlich nutzen das viele Spamer um ihrer Nachricht Nachdruck zu verleihen in der Hoffnung der Text würde dann fett dargestellt. [i] und [u] wird zu mindestens nicht angemerkt... hm. BTW: Was Paul meint ist wohl eher C im allgemeinen, was ihr bzgl. "nachvollziehbar" anmerkt hat nix mit der Syntax zu tun, die kann der Compiler sehr gut nachvollziehen egal wie ihr die Variablen nennt :P
Finde ich gut, der Automat sollte noch viel mehr auf schlechten Code-Stil achten :-)
Mir ist immer noch nicht klar, was an der Syntax von C so furchtbar schlecht sein soll. Klar kann man à la "International Obfuscated C Code Contest" absolut unleserlichen Code fabrizieren, wenn man dies absichtlich so machen will. Es gibt aber auch vernünftig geschriebenen Code, der gut zu lesen ist. Da kommt es meiner Meinung nach eher auf den Programmierer als auf die Sprache an.
>Mir ist immer noch nicht klar, was an der Syntax von C so furchtbar >schlecht sein soll. != == >> Solche Sachen meine ich. Warum muß Etwas noch gleicher sein als gleich? Auf dem Papier und in der Marthematik ist das: <> ungleich und nicht so ein Ding: != Weiß der Teufel, wie die Erfinder darauf gekommen sind. Warum gibt es "Universalvariablen", die alles und jedes aufnehmen können, egal wie "dick" es ist? C ist auch nicht so portabel, wie es immer heißt. Hat man einen neueren Compiler, hustet und spuckt der, wenn er Quelltext von einer älteren Version verarbeiten soll. Die meisten Leute hier werden Ingenieure oder Techniker sein; sie lernen C im Studium. Deshalb sind wahrscheinlich auch viele, viele Programmbeispiele hier im Forum in dieser Sprach erstellt. So eine schön strukturierte Sprache wie Pascal (oder Algol, auch auch Basic) ist doch viel einfacher zu erlernen, weil der Quelltext fast schon "Umgangssprache" enthält. MfG Paul
Paul Baumann schrieb: > Auf dem Papier und in der Marthematik ist das: <> ungleich und nicht > so ein Ding: != Na, Paul, wann hast du das letzte Mal ein "ungleich" aufs Papier geschrieben? ;-) ≠ wird das geschrieben... Da finde ich "!=" schon mal näher dran als "<>". Es gibt Dinge, die an der C-Syntax wirklich schräg sind, den ternären Operator (es gibt nur einen ternären) verwendet man beispielsweise nur in seltenen Fällen sinnvoll. Wo ich dir Recht geben würde ist, dass die Benutzung von := als Zuweisungsoperator und = als Vergleichsoperator besser zu klassischen mathematischen Gewohnheiten passt als = und ==. Anweisungen wie i = i + 1 sollen wohl schon manchem Mathematiker die Haare zu Berge stehen lassen haben in der Anfangszeit der Computerei, als noch nicht jeder Mensch dieses Berufszweiges auch zugleich Übung in der Programmierung von Computern hatte. ;-)
Paul Baumann (paul_baumann) schrieb: > So eine schön strukturierte Sprache wie Pascal (oder Algol, auch auch > Basic) ist doch viel einfacher zu erlernen, weil der Quelltext fast > schon "Umgangssprache" enthält. Pascal ist eine geschwätzige Sprache BASIC ist eine Anfängerspache die nicht gut tut ;) Algol ? Hmm .. hatte nie was damit zu tun (oder vergessen ;))
@Jörg > ≠ wird das geschrieben... Ja, auf dem Papier habe ich das lange nicht gemacht, das stimmt, aber in Pascal und auch in Bascom ist ungleich: "<>". @Michael M. >paul: sry, aber damit hast du dich komplett disqualifiziert... ...Wofür disqualifiziert? -für den Abfahrtslauf der Damen...? ;-) MfG Paul
Paul Baumann schrieb: > Ja, auf dem Papier habe ich das lange nicht gemacht, das stimmt, aber in > Pascal und auch in Bascom ist ungleich: "<>". In Pascal und in BASIC (wobei andere BASIC-Dialekte dafür # benutzen), aber eben nicht auf dem Papier und in der Mathematik. ;) Pascal und BASIC haben hier genauso eine willkürliche Entscheidung getroffen wie C, damit sie das im ASCII-Zeichensatz nicht vorhandene Zeichen ≠ irgendwie ersetzen konnten.
Paul, das ist einfach nur Gewohnheitssache. Wenn du lange genug C
programmiert hast, dann gewöhnst auch du dich dran.
Im Übrigen ist es doch etwas bequemer, statt begin nur { schreiben zu
müssen - der Informationsgehalt ist derselbe.
Und wie für andere Programmiersprachen gilt natürlich auch für C:
Zeilenumbrüche, Einrückungen und Leerzeichen machen den Code deutlich
lesbarer, wenn sie häufig genug und mit Verstand eingesetzt werden.
Viel abartiger, als C, finde ich perl und das Abartigste in dieser
Richtung ist wohl APL.
Uhu Uhuhu schrieb: > Im Übrigen ist es doch etwas bequemer, statt begin nur { schreiben zu > müssen - der Informationsgehalt ist derselbe. Wobei ich Pascals Geschwätzigkeit durchaus mag. 10-Finger-Schreiben kann ich schon lange, und C mit seinen geschweiften Klammern kann man auf einer originalen deutschen Tastatur, so wie sie sich IBM mal ausgedacht hat, eigentlich nicht schreiben. (Mein keyboard layout ist seit 20 Jahren dahingeheng gehackt, dass ich da, wo die meisten Leute Umlaute tippen, eckige und geschweifte Klammern habe.) > Viel abartiger, als C, finde ich perl Naja, Perl unterscheidet sich, wenn man es "normal" benutzt, nur wenig von C. Konstrukte wie nachgesetzte Bedingungen können den Code manchmal lesbarer machen, bspw. statt
1 | if (!/^$/) {
|
2 | # empty line |
3 | next; |
4 | } |
schreiben zu können:
1 | next unless /^$/; # empty line |
In nahezu jeder Programmiersprache kann man komplett verhunzten Code zimmern, wenn man nur will.
@Jörg >dahingeheng gehackt, dass ich da, wo die meisten Leute Umlaute tippen, >eckige und geschweifte Klammern habe.) Na, da bin ich ja optimal vorbereitet, denn mein Müh- und Notebook hat ein englisches Tastaturlayout. :-) @Uhu Ich habe mit Algol angefangen zu programmieren (auf dem KRS4201) http://www.robotrontechnik.de/index.htm?/html/computer/r4201.htm Später dann ging es mit Turbo-Pascal weiter. Das prägt die Programier- weise und man will sich dann in scheinbar verquere Sprachen nicht einarbeiten. Aber ich werde es wohl müssen... Zum Schluss noch ein Zitat von Nikolaus Wirth, der Pascal erfand: "C ist keine ‘high level programming language’. C ist ein mit Syntax verzuckerter Assembler" MfG Paul
Paul Baumann schrieb: > Na, da bin ich ja optimal vorbereitet, denn mein Müh- und Notebook hat > ein englisches Tastaturlayout. :-) Damit wiederum tippen sich Umlaute recht schlecht. Die will ich als jemand, der Deutsch als Muttersprache spricht, nun auch wieder schreiben können. (Kompromiss ist, dass ich für die Umlaute den rechten Daumen zur AltGr-Taste bemühen muss, dann geben sie die Zeichen, die drauf stehen. :)
Paul Baumann schrieb: > "C ist keine ‘high level programming language’. C ist ein mit Syntax > verzuckerter Assembler" Ja, das sehe ich auch so. Das ist der Charm von C. Aber so wie ich Wirth kenne, verbirgt sich hinter seiner Äußerung auch ein gewisser Spott, weil C mit einem Bottom-Up-Parser verarbeitet wird und deswegen gewöhnungsbedürftige Fehlermeldungen produziert, während Pascal eine Top-Down-Sprache mit den entsprechenden Vorteilen bei der Fehleranalyse ist.
Plump in die Kerbe gehauen: Wer nichts wird, wird Wirth.
Rufus t. Firefly schrieb: > Plump in die Kerbe gehauen: > Wer nichts wird, wird Wirth. LOL! :-)))
Program Rufus_Zurechtweisung;
Uses CRT;
Begin
Clrscr;
Writeln ('Pass nur auf, dass Dir der Nikolaus nicht mit der Rute
kommt')
Writeln ('wenn Du solche Parolen ausgibst....')
End.
Flücht
Paul
Um mal etwas Lesestoff für die Diskussion um C beizusteuern: http://www.henning-thielemann.de/CHater.html Das ist sehr lesenswert, insbesondere die Tabelle in der Mitte. Die sollte sich jeder C-Entwickler (ja, bin ich oft auch) mal zu Gemüte führen. :) http://www.henning-thielemann.de/CHater.html#CvsM3_ControlFlow Und ja, man merkt, dass C von Fricklern "entwickelt" wurde. Viele Sachen sind einfach saudumm gelöst; insbesondere die ganzen kranken "Vereinfachungen" in der Syntax dürften schon Milliarden an Entwicklerstunden bei der Fehlersuche oder dem Versuch, fremden Code zu verstehen, gekostet haben.
Die Tabelle habe ich mir mal teilweise angesehen. Eine schöne Auflistung von Dingen, die vielen das Leben einfacher machen, aber auch zur Stolperstelle für die werden, die zu blöd sind mit Freiheit umzugehen. Beispiel: Geschweifte Klammern und else Rechts, wie man wohl in Modula-3 gezwungen ist es zu machen, links die Freiheit, die C lässt um für einen Zeile zwei (im Vergleich zu Modula-3 sieben) Zeichen zu sparen. Wer damit nicht klar kommt, kann die Klammern setzten und spart immer noch fünf Zeichen.
Scheint aber sowieso eher eine Seite zu sein, die Modula-3 pushen will und dafür erst mal versucht, den größten Konkurrenten aus dem Weg zu Räumen.
Ich kann der Liste nicht so furtbar viel Schlimmes über C abgewinnen ;-) Was mich an C wirklich stört, kritisiert er nicht:
1 | while (a) {
|
2 | ... |
3 | while (b) {
|
4 | if (fertig) |
5 | goto done; |
6 | } |
7 | ... |
8 | } |
9 | done: |
Deutlich menschenfreundlicher fände ich, wenn man Schleifen labeln könnte und dann mit Hilfe des Labels strukturiert aussteigen:
1 | outer: while (a) {
|
2 | ... |
3 | while (b) {
|
4 | if (fertig) |
5 | break outer; |
6 | } |
7 | ... |
8 | } |
Paul Baumann schrieb: > Writeln ('Pass nur auf, dass Dir der Nikolaus nicht mit der Rute > kommt') Syntax error: missing semicolon before next statement.
Gastino G. schrieb:
> Und ja, man merkt, dass C von Fricklern "entwickelt" wurde.
Nur gut, dass Gastino G. der Kluge Weise ist, auf den alle gewartet
haben.
Dumm nur, dass er vermutlich noch nie vor der Aufgabe stand, einen
Compiler für eine benutzbare Programmiersprache zu bauen, der
mit insgesamt 64 KiB für Daten und Programmcode für einen Pass
auskommen muss und es trotzdem dem Anwender ermöglichen sollte,
maximal die Möglichkeiten der Maschine zu nutzen. Dinge wie
"*pointer++" gehören in diese Kategorie, die entsprechenden
Adressierungsmodi der PDP-11 hätten sich Anfang der 1970er Jahre
einfach in einer anderen Programmiersprache als C nicht nutzen
lassen können. (Daher findet man in altem C-Code praktisch auch
nur *p++ und --*p, nie aber die entgegengesetzten Varianten, denn
die hatten kein Hardwareäquivalent auf der PDP-11.)
Mittlerweile können Compiler und die Maschinen, auf denen sie
laufen, natürlich deutlich mehr, man bräuchte also eigentlich kein
C mehr. ;-) Aber die Leute haben sich halt so gut dran gewöhnt...
Uhu Uhuhu schrieb: > Deutlich menschenfreundlicher fände ich, wenn man Schleifen labeln > könnte und dann mit Hilfe des Labels strukturiert aussteigen: Das hat Perl dann der von C übernommenen Syntax hinzu gefügt. ;-)
@Jörg Du bist ein aufmerksamer Compiler! ;-) Ich war mehrfacher DDR-Meister im Semikolon-Vergessen... MfG Paul
Jörg Wunsch schrieb:
> Das hat Perl dann der von C übernommenen Syntax hinzu gefügt. ;-)
Das versöhnt mich nicht mit Perl...
Jörg Wunsch schrieb: > Dumm nur, dass er vermutlich noch nie vor der Aufgabe stand, einen > Compiler für eine benutzbare Programmiersprache zu bauen, der > mit insgesamt 64 KiB für Daten und Programmcode für einen Pass > auskommen muss und es trotzdem dem Anwender ermöglichen sollte, > maximal die Möglichkeiten der Maschine zu nutzen. Schön. Und genau mit diesem Denkansatz schafft man Werkzeuge, die ein derart großes Fehlerpotential wie C mitbringen. Und das ist Frickelei! Mal abgesehen davon, dass sich mir der Zwang zu der teilweise undurchdachten und Fehler begünstigenden Syntax nicht wirklich erschließt.
@Gastino G. Ich halte das alles für Geschmacksache und über Geschmack kann man bekanntlich nicht streiten. Nicht nur mit C kann man groben Unfug anstellen. Um das zu vermeiden, muß man sich eben gewisse Routinen angewöhnen. Daß Anfänger zuweilen ins Schwitzen kommen, ist auch nichts besonderes.
Uhu Uhuhu schrieb: > Ich halte das alles für Geschmacksache und über Geschmack kann man > bekanntlich nicht streiten. Ich würde das nicht als Geschmackssache bezeichnen. Die Syntax einer Sprache ist auch ein Teil der Architektur und die kann eben mehr oder weniger durchdacht sein. Bei manchen Sprachen wurde viel an Energie investiert, um Fehlerquellen so gut wie möglich auszuschließen und bei manchen scheinen sich die Ersteller überhaupt keine Gedanken darüber gemacht zu haben. Zu letzterer Gruppe gehört (unnötigerweise!) C, was bei einigermaßen sicherheitskritischen Anwendungen wieder Dinge wie zum Beispiel MISRA-C erfordert, um wenigstens einige der Fehlerquellen und Fallstricke von C zu beseitigen. Es ist ja nicht nur die Syntax, es sind ja auch viele Lücken in der Spezifikation, die teilweise unerwartetes Verhalten der Software hervorrufen können. Zu MISRA-C ein paar Worte hier: http://www.elektroniknet.de/home/embeddedsystems/fachwissen/uebersicht/software/entwicklungssoftware/der-programmierstandard-misra/
Derlei Probleme in den Griff zu bekommen, gibt es ein probates Mittel: lint.
Gastino G. schrieb: > Es ist ja nicht nur die Syntax, es sind ja auch viele Lücken in der > Spezifikation, die teilweise unerwartetes Verhalten der Software > hervorrufen können. Oh, oh. Seit 1989 ist C außerordentlich gut spezifiziert, und seit 1990 sogar ein ISO-Standard. Das größere Problem ist, dass viele Leute, die diese Sprache benutzen, den Standard nie gesehen haben und offenbar auch kein Interesse daran haben, ihn sich anzugucken (und das, obwohl er anders als viele andere Standards [einschließlich MISRA bspw.] de facto komplett frei zugänglich ist). Wenn sich jeder daran halten würde, Dinge, die im Standard als "undefined" markiert sind, auch tatsächlich nicht zu tun und Sachen, die "implementation- defined" sind wirklich nur so zu benutzen, dass man bei der Portierung auf eine andere Implementierung mit der Nase drauf gestoßen wird, dann wäre die Welt eine bessere. ;-)
Spam geht ohne Probleme durch den Filter hier, also beklagt euch nicht:
1 | char mein_laden_ist_der_beste[] = "Bananenladen 2000"; |
2 | bool meine_bananen_sind_die_besten = true; |
3 | float bei_mir_kostet_ein_bund_bananen_nur = 2.50; |
4 | |
5 | /* Heute Aktion */
|
6 | bei_mir_kostet_ein_bund_bananen_nur = 2.00; |
Jörg Wunsch schrieb: > Oh, oh. Seit 1989 ist C außerordentlich gut spezifiziert, und seit > 1990 sogar ein ISO-Standard. Das größere Problem ist, dass viele > Leute, die diese Sprache benutzen, den Standard nie gesehen haben > und offenbar auch kein Interesse daran haben, ihn sich anzugucken Das siehst du doch schon auf der von Gastino verlinkten C-Hater-Seite. Da macht sich jemand die Muehe, eine ganze Seite ueber seinen C-Hass zu produzieren, aber mal einen Blick in ein C-Buch zu werfen ist ihm zu anstrengend. Das sieht man schon daran, dass er Pascal-typisch staendig Semikolons setzt, wo sie in C ueberfluessig sind. Schlimmer ist aber, dass er offensichtlich grundlegende semantische Konstrukte ("statement") gar nicht kennt. An C kann man viel kritisieren, aber es sollte schon Fundament haben. Auch das hier hoch gelobte Pascal erscheint sehr unlogisch und kryptisch, wenn man es aus dem falschen Blickwinkel betrachtet und sich nicht mit den Grundlagen beschaeftigt.
Jörg Wunsch schrieb: > (und das, obwohl er anders als viele andere Standards [einschließlich > MISRA bspw.] de facto komplett frei zugänglich ist). Im Gegensatz zu dem ganzen VDE-Scheiß...
Jörg Wunsch schrieb: > Oh, oh. Seit 1989 ist C außerordentlich gut spezifiziert, und seit > 1990 sogar ein ISO-Standard. Das größere Problem ist, dass viele > Leute, die diese Sprache benutzen, den Standard nie gesehen haben > und offenbar auch kein Interesse daran haben, ihn sich anzugucken > (und das, obwohl er anders als viele andere Standards [einschließlich > MISRA bspw.] de facto komplett frei zugänglich ist). Wenn sich jeder > daran halten würde, Dinge, die im Standard als "undefined" markiert > sind, auch tatsächlich nicht zu tun und Sachen, die "implementation- > defined" sind wirklich nur so zu benutzen, dass man bei der > Portierung auf eine andere Implementierung mit der Nase drauf > gestoßen wird, dann wäre die Welt eine bessere. ;-) Du widersprichst Dir selber: Erst ist C außerordentlich gut spezifiziert und dann gibt es doch wieder eine ganze Menge "undefined" und "implementation defined". Wäre C "außerordentlich gut spezifiziert" und hätte eine durchdachte Syntax, bräuchte es Dinge wie MISRA-C überhaupt nicht. Du versuchst, jedes Design-Problem von C mit angeblich uninformierten Nutzern zu entschuldigen. Ich programmiere aber auch sehr häufig in C und habe mir glücklicherweise den Blick über den Tellerrand behalten können und muss das nicht krampfhaft schönreden. Es gibt eine ganze Menge Fehlerpotential bei Benutzung dieser Sprache, dass absolut nicht notwendig wäre.
gastino schrieb: > Du widersprichst Dir selber: Erst ist C außerordentlich gut spezifiziert > und dann gibt es doch wieder eine ganze Menge "undefined" und > "implementation defined". Das hat historische Gründe: Wie Wirth sagte, ist C ein syntaktisch verzuckerter Assembler. Es wurde ursprünglich entwickelt, um auf der PDP-11 das Betriebsystem Unix effizienter programmieren zu können, als in ASM. Dann wurde Unix und C auch auf andere Systeme portiert und man präzisierte die Sprachdefinition in dem Sinn, daß man die Eigenschaften der jeweiligen Hardware nicht durch die Sprache überdeckt - wieder typisch Assembler-Sicht. Der Vorteil der Methode ist, daß die Sprache nur eine dünne und leicht durchschaubare Schicht über der Hardware bildet. C ist ursprünglich eine Sprache zur Entwicklung von Systemsoftware. Sie für Anwendungsentwicklung zu benutzen, ist nicht unbedingt eine kluge Wahl - wer viele Möglichkeiten hat, kann viel Unsinn damit machen, wenn er nicht damit umgehen kann. Sprachen, die die Hardware vollständig einhüllen, wie die Pascal-Familie, Basic & Co. sind zwangsläufig weniger effizient, weil die die abstrakte Maschine, auf der die Sprache läuft, auf die reale Hardware abgebildet werden muß. Vor diesem Hintergrund ist C++ eine etwas merkwürdige Abkehr von den Grundideen von C, ohne den Assemblerblick völlig aufgeben zu wollen.
gastino schrieb: > Du widersprichst Dir selber: Erst ist C außerordentlich gut > spezifiziert und dann gibt es doch wieder eine ganze Menge > "undefined" und "implementation defined". Das widerspricht sich keinesfalls: es ist spezifiziert, was wann wo passiert. Das heißt nicht, dass man deshalb sinnvoll alles tun kann. Es ist beispielsweise auch (gewissermaßen indirekt) spezifziert, dass ein Silvesterknaller nach dem Anzünden nach einer gewissen Zeit explodiert. Wenn du ihn dann trotzdem nach dem Anzünden in der Hand behälst, dann darfst du dich hinterher nicht beim Hersteller drüber beklagen, dass er ihn nicht so konstruiert hat, dass er dir nach dem Anzünden sofort automatisch aus der Hand schnippst, damit du ja niemals in die Verlegenheit kommst, dass er dir bein unsachgemäßer Verwendung in der Hand explodieren könnte... Selbst, falls es möglich sein sollte, einen solchen Silvesterknaller zu produzieren: den wirst du nicht kaufen wollen, weil das Verhältnis von Aufwand und Nutzen nicht mehr stimmt. > Wäre C "außerordentlich gut spezifiziert" und hätte eine durchdachte > Syntax, bräuchte es Dinge wie MISRA-C überhaupt nicht. Das gibt es, heißt Ada, und hat sich seltsamerweise in dem Bereich, der von MISRA reguliert wird, offenbar nicht durchsetzen können. Das liegt nun ganz gewiss nicht am Mangel an Compilern dafür oder an der fehlenden Sprachdefinition. > Du versuchst, jedes Design-Problem von C mit angeblich > uninformierten Nutzern zu entschuldigen. Nein. Ich sehe es nur pragmatisch: C ist nicht der Stein der Weisen, taugt aber, wenn man die Sprache nur beherrscht, als Alltagsmittel gar nicht so schlecht, wie manche tun. Dass man damit auch Mist machen kann, ist mir völlig klar, und dass es den Programmierer nur wenig davon abhält, Mist zu machen, ebenfalls. Es gehört ein gewisses Maß an Selbstdisziplin dazu, dass man Software, die auch das Ende des Tages überleben soll, so niederschreibt, dass sie dieses Fehlerpotenzial nicht ausreizt. Falls du glaubst, ich kenne nur C und müsste es deshalb "schön reden": ich habe in meinem Leben bislang in BASIC, FORTRAN, Pascal (zwei verschiedene Dialekte), C, C++, Perl, Python, ein wenig Lisp (Emacs) und diversen Assemblern (PDP-11, Z80, Z8, m88000, PIC, AVR) programmiert. Ich weiß aus Erfahrung, dass es auf die tatsächliche Programmiersprache eher wenig ankommt. ;-) Uhu Uhuhu schrieb: > Das hat historische Gründe: Wie Wirth sagte, ist C ein syntaktisch > verzuckerter Assembler. Es wurde ursprünglich entwickelt, um auf der > PDP-11 das Betriebsystem Unix effizienter programmieren zu können, als > in ASM. Dabei sollte man nicht unerwähnt lassen: bis zu diesem Zeitpunkt waren Betriebssysteme in der Tat nur in Assembler gehackt, was zu Kolossen geführt hat, die man kaum noch pflegen konnte. Es ist der Verdienst von C, eine höhere Abstraktionsstufe als Assembler in die Betriebssystemprogrammierung eingeführt zu haben, aus der es bis heute nicht wieder verschwunden ist. Ein Betriebssystem auf mehr als nur einem Prozessor benutzen zu können und dabei weit mehr als 90 % des Codes zwischen diesen gemeinsam benutzen zu können, war 1970 komplett undenkbar. Das dürfte aber auch genau der Grund sein, warum diese Sprache bei Controllern ihre Verbreitung gefunden hat: dort gibt es sehr oft kein Betriebssystem, und die typischen Aufgaben des Controller- Programmierers gleichen im hohen Maßen denen des Betriebssystemprogrammierers einer PDP-11.
Uhu Uhuhu schrieb: > Das hat historische Gründe: Wie Wirth sagte, ist C ein syntaktisch > verzuckerter Assembler. Es wurde ursprünglich entwickelt, um auf der > PDP-11 das Betriebsystem Unix effizienter programmieren zu können, als > in ASM. Jaein. C ist schon eine Hochsprache, wenn auch sehr hardwarenah. Die Abstraktionsebene finde ich bei C auch sehr praktisch und nicht nur ich. Trotzdem ist die Umsetzung teilweise schlampig. Jörg Wunsch schrieb: > Das widerspricht sich keinesfalls: es ist spezifiziert, was wann wo > passiert. Das heißt nicht, dass man deshalb sinnvoll alles tun > kann. Also wenn etwas "undefined" oder "implementation defined" ist, dann ist es eben nicht spezifiziert. Jörg Wunsch schrieb: > Das gibt es, heißt Ada, und hat sich seltsamerweise in dem Bereich, > der von MISRA reguliert wird, offenbar nicht durchsetzen können. Das > liegt nun ganz gewiss nicht am Mangel an Compilern dafür oder an der > fehlenden Sprachdefinition. Im Automobilbereich ist der Hauptgrund, warum sich ADA nicht durchsetzen konnte, die schlechte Verfügbarkeit von Compilern. Jörg Wunsch schrieb: > Ich sehe es nur pragmatisch: C ist nicht der Stein der Weisen, > taugt aber, wenn man die Sprache nur beherrscht, als Alltagsmittel gar > nicht so schlecht, wie manche tun. Sehe ich ebenso. Allerdings wäre etwas mehr Nachdenken und etwas weniger Frickelei bei der Entwicklung dieser Sprache durchaus angebracht gewesen.
Gastino G. schrieb: > Also wenn etwas "undefined" oder "implementation defined" ist, dann ist > es eben nicht spezifiziert. Doch, ist es, denn es ist genau klar, was davon betroffen ist. Man kann sich höchstens noch drüber streiten, ob man nicht manche Dinge, die "implementation-defined" sind (bspw. bitfields) hätte besser doch festschreiben sollen, um ihre portable Benutzbarkeit zu gewährleisten. An vielen derartigen Stellen wollte man offenbar aus Performancegründen die Implementierer lieber nicht so sehr einschränken. > Sehe ich ebenso. Allerdings wäre etwas mehr Nachdenken und etwas weniger > Frickelei bei der Entwicklung dieser Sprache durchaus angebracht > gewesen. Mit Verlaub, du bist entweder ein Spinner oder ziemlich arrogant. 40 Jahre später sieht die Welt immer ganz anders aus. Versuch doch mal, dich in ein Projekt von einer handvoll Leuten ins Jahr 1970 zu versetzen, die es sich zur Aufgabe gemacht haben, die volle Performance der Maschine nach oben zu reichen, damit man den schwer wartbaren Assemblercode aus der Systemprogrammierung ablösen kann, und die mit den damaligen Erfahrungen und den Resourcen der benutzten Systeme auch tatsächlich implementierbar war. Denk dran, ein großes, nicht praktikabel implementierbares Projekt (Multics) hatten diese Leute soeben hinter sich gelassen damals... Sie haben da wohl reichlich Neuland beschreiten dürfen. Die dabei gemachten Fehler und Priorisierungen (bspw. auf Performance anstelle in jeglicher Hinsicht starr festgelegter Eigenschaften) mit dem Abstand von 40 Jahren als "Frickelei" abzutun, finde ich einfach nur überheblich.
Jörg Wunsch schrieb:
> Mit Verlaub, du bist entweder ein Spinner oder ziemlich arrogant.
Und Du hast nicht die nötigen Umgangsformen, die für eine weitere
Diskussion mit mir notwendig wären.
Gastino G. (gastino) schrieb: Jörg Wunsch schrieb: >> Mit Verlaub, du bist entweder ein Spinner oder ziemlich arrogant. > Und Du hast nicht die nötigen Umgangsformen, die für eine weitere > Diskussion mit mir notwendig wären. Na jetzt sei nicht gleich beleidigt wenn ein langjähriger Kenner auf diesem Gebiet mal einen historischen Abschnitt illustriert und dabei mit einem kleinen Aufreger würzt. Jörg Wunsch kann sich dabei vielleicht etwas besser in jene hineinversetzen, die damals unter viel schwierigeren Bedingungen (wenig Rechenleistung, Speicher, spärliche Informationen usw. usw.) sowas wie C zustande bringen mussten.
Gastino G. schrieb: > Und Du hast nicht die nötigen Umgangsformen, die für eine weitere > Diskussion mit mir notwendig wären. Gehts noch?
Gast2 schrieb: > Jörg Wunsch kann sich dabei vielleicht > etwas besser in jene hineinversetzen, die damals unter viel > schwierigeren Bedingungen (wenig Rechenleistung, Speicher, spärliche > Informationen usw. usw.) sowas wie C zustande bringen mussten. Die Bedingungen für das Erstellen einer durchdachten Sprache inklusive Syntax, die nicht zu Fehlern geradezu einlädt, waren damals sicher nicht schwieriger als heute, zumindest hat das mit der Rechenleistung an sich nicht viel zu tun. Schließlich haben viele Programmiersprachen ihre Wurzeln in der Zeit. Auch solche, bei denen die Ersteller etwas planvoller vorgegangen sind. Uhu Uhuhu schrieb: > Gehts noch? Wieso fragst Du mich das? Ich bezeichne andere hier nicht als Spinner und verbitte mir solche Umgangsformen.
Gastino G. schrieb: > Jörg Wunsch schrieb: >> Mit Verlaub, du bist entweder ein Spinner oder ziemlich arrogant. > > Und Du hast nicht die nötigen Umgangsformen, die für eine weitere > Diskussion mit mir notwendig wären. wenn du nur wüsstest, wen du da so unangemessen anredest, würde dir die galle freiwillig hochkommen.
Michael M. schrieb: > wenn du nur wüsstest, wen du da so unangemessen anredest, würde dir die > galle freiwillig hochkommen. Du kannst Dich meinetwegen mit Freude als Spinner titulieren lassen, wenn Dir das gefällt. Ich habe das weder nötig, noch akzeptiere ich das als "normale Umgangsform". Von niemandem. Dass hier Moderatoren ihre eigenen Nutzungsbedingungen verletzen, ist schon ein starkes Stück. Dass sich derjenige, der beleidigt wird, noch dafür bedanken soll, ist echt die Höhe...
Gastino G. schrieb: > Du kannst Dich meinetwegen mit Freude als Spinner titulieren lassen, > wenn Dir das gefällt. Ich habe das weder nötig, noch akzeptiere ich das > als "normale Umgangsform". Von niemandem. wenn du dich danebenbenimmst, wird dir das gesagt. im idealfall von jedermann. > Dass hier Moderatoren ihre eigenen Nutzungsbedingungen verletzen, ist pecunia non olet, homo olet. wenn du hässlich wie die nacht finster bist, werde ich dir das auch ins gesicht sagen, wenn du dich als adonis aufspielst. du bist ein arroganter spinner (ja, für mich sogar beides), also musst du dir das auch sagen lassen. > schon ein starkes Stück. Dass sich derjenige, der beleidigt wird, noch > dafür bedanken soll, ist echt die Höhe... muss in meinen augen nicht sein. aber einsicht stünde dir gut zu gesicht.
Gastino G. schrieb: > Schließlich haben viele Programmiersprachen ihre > Wurzeln in der Zeit. Auch solche, bei denen die Ersteller etwas > planvoller vorgegangen sind. Keine einzige davon war aber in der Lage, dass man damit hätte ein Betriebssystem auf einer PDP-11 implementieren können. Keine einzige davon hat es geschafft, die volle Leistung der Maschine (wie das genannte pre-decrememt und post-increment indirect addressing) in der Hochsprache nutzbar zu machen. Es wurde einfach mal ein radikal anderer Ansatz gebraucht, als Algol oder FORTRAN geboten haben. Systeme wie Oberon datieren auf stolze 15 Jahre später. Oberon kannst du vielleicht als den Zeitpunkt ansehen, an dem man mit einer Pascal-ähnlichen Sprache in der Lage war, ein Betriebssystem zu bauen. Das war aber dann bereits eine 32-bit-Maschine (NS32k), auf der das implementiert wurde, und die Compilertechnologie war entsprechend auch weiter fortgeschritten.
Um der Wahrheit Genüge zu tun, muss man aber auch erwähnen, dass es durchaus auch andere Ansätze gab. PL/I war ein Sprachmonster. Einen Compiler dafür zu bauen, war extrem schwer (ob es IBM jemals gelang ihre eigene Spec. exakt einzuhalten, lass ich mal im Raum stehen). Eine Abart davon, PL/M, wurde immerhin benutzt um CP/M zu implementiern. Und das war dann doch zu seiner Zeit recht verbreitet. Warum es Unix bzw. C trotzdem geschafft haben? Meiner Meinung nach war einer der Hauptgründe, dass AT/T lange Zeit nicht wusste, welchen Schatz sie da geboren hatten. Jeder der wollte, konnte den Quelltext kriegen. Und: Unix war ein radikal anderer Ansatz als die Betriebssysteme der damaligen Zeit: schlank, einfache Befehle, die volle Leistungsfähigkeit erschliest sich erst durch Kombination der einfachen Dinge. Das war radikal unterschiedlich zu allem was es davor gab. Wer je ein IBM JCL Manual in den Fingern hatte, weiß wovon ich rede. Für praktisch jedes auftretende Problem wurde einem Standardprogramm wieder ein neuer Schalter hinzugefügt. Das JCL Manual lässt umfangmässig 'Krieg und Frieden' wie einen Werbefolder aussehen :-) Auch DEC war mit seinem RS/X noch in dieser Schiene gefangen. Die Schalterflut des PIP (Peripheral Interchange Program, heute würde man Copy dazu sagen) ist legendär. Mit den ersten PDP konnte man nicht wahnsinnig viel anfangen. Dazu waren sie zu klein und das Betriebsystem zu umfangreich. Während DEC den Weg ging, die PDP weiter aufzurüsten und ihr so zu ihrem Siegeszug verhalf, der erst von der VAX aus gleichem Haus gestoppt werden konnte, existierte da plötzlich ein alternatives BS, mit dem man auch die kleinen PDPs sinnvoll einsetzen konnte. Ein gefundenes Fressen für Uni-Institute, die gerne einen eigenen Computer gehäbt hätten, aber budgetmässig nicht in der Lage waren, sich eine IBM samt nötigem Umfeld (klimatisierter Raum) anzuschaffen. Wie Jörg schon sagte: Es ist einfach, sich heute hinzusetzen und zu mosern. Klar hätte man vieles anders machen können. Auch in C++ gibt es genügend Stellen, die Stroustroup viel besser hätte hinkriegen können. Die Geschichte zeigt allerdings auch, dass gerade Programmiersprachen die komplett am Reissbrett entstanden sind, meistens entweder Monster oder Totgeburten wurden. C ist aus der praktischen Notwendigkeit entstanden, so etwas wie einen portablen Assembler zu benötigen. Seine Vorgängersprachen waren noch typenlose Sprachen und ich möchte nicht wissen, welche Grabenkämpfe ausgefochten werden mussten, um den vermeintlichen Nachteil einer strenger typisierten Sprache gegen den Zuwachs an Sicherheit durch eben jene Typisierung zu akzeptieren, die es in Assembler auch nicht gibt. (nur um jetzt ein Detail herauszugreifen, dass C von zb B unterscheidet) Niemand streitet ab, dass C im Grunde ein besserer Assembler ist, der sich über die Jahre (auch durch den Einsatz der Normungsgremien) zu einem Allzweck-Geländewagen gemausert hat. Seine Herkunft kann C nicht verleugnen, will es auch nicht. Aber es ist auch genau diese Herkunft, mit all seinen daraus resultierenden Kanten und Ecken, die C zu seiner Popularität verholfen hat. Eine Sprache, geboren aus der Praxis, gemacht für die Praxis. Und natürlich, dass der Compiler selbst weitgehend in C geschrieben war und gratis verteilt wurde.
Anzumerken sei auch noch, daß unter den in diesem Forum auftretenden Personen Jörg sicherlich jemand ist, der zu den absoluten Spitzenkräften in Sachen C- und C++-Programmierung gehört. Liest man seine Kommentare, die er bei kniffligen C- oder auch C++-Fragen abgibt, so wird klar, daß er nicht nur weiß, daß es eine Sprachspezifikation gibt, sondern daß er die auch noch kennt. Insofern (und nicht nur soweit) Hut ab. Und ich kann in Anbetracht des "Zwischenfalls" zwischen "Gastino" und Jörg Jörgs Tonfall komplett nachvollziehen. "Gastino" ist hier mit heftigster Kritik am Forum aufgetaucht, in der er durch die Blume den Befürwortern des Status Quo Ewiggestrigkeit unterstellt hat, und ist zumindest mir noch nicht als wirklich inniger Kenner von Dingen aufgefallen. Ich will nicht ausschließen, da etwas übersehen zu haben, aber der Eindruck, der sich bei mir bildet, ist mehr der ätzende, wenn auch eloquente Kritiker, als der eine Sprache, ein Produkt, ein irgendwas äußerst genau kennende hilfsbereite Mensch, als der mir z.B. Jörg oder auch Karl-Heinz mit seiner Engelsgeduld und exzellenten lehrbuchartigen Erklärungen aufgefallen sind.
Rufus t. Firefly schrieb: > Und ich kann in Anbetracht des "Zwischenfalls" zwischen "Gastino" und > Jörg Jörgs Tonfall komplett nachvollziehen. "Gastino" ist hier mit > heftigster Kritik am Forum aufgetaucht, in der er durch die Blume den > Befürwortern des Status Quo Ewiggestrigkeit unterstellt hat Wo habe ich das? Ich habe geschrieben, dass ich selber sehr häufig C nutze, aber trotzdem viele Dinge dort nicht sonderlich glücklich gelöst finde und da bin ich bei weitem nicht allein (siehe MISRA-C, das in der Automobilindsutrie "Standard" ist). Und das meiste hat mit der notwendigen Hardwarenähe und geringem Ressourcenverbrauch überhaupt nichts zu tun. Daraus nun eine Begründung herzuleiten, andere als "Spinner" zu titulieren, sei in Ordnung, ist an den Haaren herbeigezogen. Völlig unabhängig davon, wer hier wen für schlauer oder dümmer hält, den er gar nicht kennt. Wenn es aber heißen soll, dass es hier entgegen Eurer eigenen Nutzungsbedingungen üblich ist, Leute mit anderen Ansichten als Spinner oder Idioten oder sonstiges zu titulieren, dann ist das ein echtes Armutszeugnis. Genauso wie die Tatsache, dass Ihr hier Dritte (Michael M.), die mit der Diskussion gar nichts zu tun haben, einfach so auf unterstem Niveau pöbeln lasst.
> Wo habe ich das?
Gelesen? "Kritik am Forum", da geht es unter anderem um den
"Gruselforum"-Thread.
Ansonsten nimmst Du den "Spinner" vielleicht auch etwas zu persönlich,
bzw. verstehst ihn (willentlich?) anders, als Jörg ihn gemeint hat.
Bist Du Dir überhaupt darüber im klaren darüber, was "mit Verlaub"
bedeutet?
Michael M. schrieb: > wenn du dich danebenbenimmst, wird dir das gesagt. im idealfall von > jedermann. Das halte ich insofern für unglaubwürdig, als das im Forum "Ausbildung & Beruf" ständig Leute ungestraft Schwachsinn posten ;-)
Rufus t. Firefly schrieb: > Gelesen? "Kritik am Forum", da geht es unter anderem um den > "Gruselforum"-Thread. Du meinst die Threads, in denen man sofort heftigst angegriffen wurde, wenn man Verbesserungsvorschläge gemacht hat? Wo man sofort unterstellt bekommt, hier Blinki-Bunti einführen zu wollen, nur weil man für Threads mit tausenden Einträgen eine optionale Unterteilung in Seiten wünscht? Ganz schlechtes Beispiel, denn in diesen Threads wird meist nach ein oder zwei Beiträgen irgendeiner persönlich, der am liebsten niemals etwas verändern würde. Und ab dann ist der Umgangston im Keller. Leider ist ja der Gruselforums-Thread verschwunden, da kann auch keiner mehr nachprüfen, wer war was auf wen geantwortet hat. Mal abgesehen davon, dass das mit dem Thema hier ja nun nichts zu tun hat. > Bist Du Dir überhaupt darüber im klaren darüber, was "mit Verlaub" > bedeutet? Ja. Es ist eine formelhafte Redensart, mit der sich der Verwender meistens als ausreichend geschützt sieht, wenn er "unangenehme" Dinge aussprechen möchte. Er bittet quasi im Voraus um Erlaubnis, um sich von schuldhaftem Tun (selbst) freizusprechen. Das Problem an der Sache ist nur, dass die Annahme, eine Erlaubnis sei gegeben, auch dem Verwender von vornherein als falsch bekannt ist. Oder um es kurz zu sagen: Es ist eine Floskel, die zeigt, dass der Verwender sich durchaus bewusst ist, dass er etwas Falsches tut. Aber wie auch immer, für mich ist die Sache jetzt erledigt. Nimm es einfach als meinen Verbesserungsvorschlag für das Forum hin, dass Pöbeleien in Zukunft unterbleiben bzw. wesentlich konsequenter gelöscht werden.
Gastino G. (gastino) wrote: > Gast2 schrieb: >> Jörg Wunsch kann sich dabei vielleicht >> etwas besser in jene hineinversetzen, die damals unter viel >> schwierigeren Bedingungen (wenig Rechenleistung, Speicher, spärliche >> Informationen usw. usw.) sowas wie C zustande bringen mussten. > Die Bedingungen für das Erstellen einer durchdachten Sprache inklusive > Syntax, die nicht zu Fehlern geradezu einlädt, waren damals sicher nicht > schwieriger als heute, Woher möchtest du das wissen? Hast du die Zeit miterlebt? > zumindest hat das mit der Rechenleistung an sich > nicht viel zu tun. Bei C? Also ich habe C immer als eine Sprache verstanden mit der man sehr effizienten Code schreiben kann und Effiziens ist nach meinem Erachten dort gefragt, wo Rechenleistung und damit Ausführungsgeschindigkeit ein begrenzender Faktor ist und/oder geringer Speicherverbrauch des Compilats. > Schließlich haben viele Programmiersprachen ihre > Wurzeln in der Zeit. Auch solche, bei denen die Ersteller etwas > planvoller vorgegangen sind. Habe leider die Pläne dieser (wohl zumeist) Herren nie zu Gesicht bekommen, deswegen kann ich die Wahrheit dieser Aussage nicht abschließend verifizieren. > .. eine formelhafte Redensart, mit der sich der Verwender > meistens als ausreichend geschützt sieht, wenn er "unangenehme" Dinge > aussprechen möchte. "Spinner" muss im Ausdruck nicht zwangsläufig negativ beleidigend sein. Vielleicht wird auch nur mal "herumgesponnen", was ja gerade ein Kennzeichen von Kreativen Geistern ist, die Abseits aller Konventionen die Dinge neu bzw. in einem anderem Licht betrachten. Mir gefallen Jörg's Texte jedenfalls, ebenso wie die von KH Buchegger zum hier genannten Thema und ich lese sie immer gerne. ;)
Ich als Wenig- und Hobbyprogrammierer will mal auch meinen Senf dazugeben. Die Fehler der Vergangenheit sind nun mal da. Ist immer so. Rumzumosern ala "Die Deppen, was haben die denn damals verbockt!". ist am Ende arrogant und sinnlos. ABER!!! Warum macht man nicht einfach mal Tabula Rasa und räumt C gründlich auf? Ob man das dann C2000 oder C* oder Super-C nennt ist Wurscht, da sollen sich mal die Marketingfuzzis den Koks durch die Nase ziehen und was ausdenken. Und dann nimmt man halt die neue Sprache für neue Projekte. Die alten Projekte werden im "alten" C beendet und weitergepflegt, wenn sinnvoll und notwendig halt portiert. JAAA, das ist Aufwand, aber den gibt es so oder so. Wenn nicht früher, dann später. Und die neuen Sprachen werden ja auch genutzt. So long Falk P S http://m5p.com/~pravn/foot.html
Falk Brunner schrieb:
> Warum macht man nicht einfach mal Tabula Rasa und räumt C gründlich auf?
Java?
array[ b ] ist noch immer Spam. Das hat jetzt zu mehr als 60 Beiträgen geführt, die aber mehr als Offtopic sind! Vielleicht klärt mich auch mal einer auf, warum das 'b' in den eckigen Klammern als Spam verdächtigt wird - hab ich da was verpasst oder in den Grundsatzdiskussionen über Programmiersprachen überlesen? :-)
weiß auch noch keiner =) thesen: wegen 4chan oder weil spammer ihren text in bb-code fett haben wollen.
Weil viele Spammer [b] und ähnliche Tags verwenden um ihre Werbung stärker hervorzuheben.
Andreas Schwarz schrieb: > Weil viele Spammer [ b] und ähnliche Tags verwenden um ihre Werbung > stärker hervorzuheben. Vielleicht kannst du ja auf [ b] ... [/b] testen?
Andreas Schwarz schrieb: > Weil viele Spammer [ b] und ähnliche Tags verwenden um ihre Werbung > stärker hervorzuheben. Das heißt also, man kann problemlos mit Fettdruck spammen, solange man nur die richtige Syntax dafür verwendet? :-)
@mark: junge, bist du... unintelligent. man kann es nicht mehr anders sagen. denk doch einfach nochmal ein bisschen über den sachverhalt nach - vielleicht kommst du dann auf den sinn dieses filters.
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.