Dein Problem ist der Scope von buchstabe in der while schleife. Dort
ist buchstabe nämlich nicht der aus dem Scope des Schleifenkörpers,
denn der gillt dort nichtmehr, sondern der aus dem Darüberliegenden
Scope.
Dashier geht:
Frank schrieb:> Was ist das denn für ein Schrott Compiler?
Das hat nichts mit einem Schrott-Compiler zu tun.
Im do-Block wird buchstabe als auto-Variable definiert, aber außerhalb
des Blocks abgefragt. Dies kann nur eine andere Variable namens
buchstabe sein, die außerhalbe dieses Blocks definiert wurde.
Das ist kein "Schrott Compiler", sondern legitimes C. Da darf eine
Variable gleichen Namens innerhalb eines Anweisungsblocks erneut
definiert werden und überblendet die Variable des äußeren Blocks. Diese
wird erst nach Verlassen des Blocks (und also Verlassen des "scopes", in
dem die innere Variable gültig ist und existiert) wieder sichtbar.
Das Programm oben sieht nach Arduino aus.
Die gcc-Option -Wshadow hätte für so eine 'Shadow Variable' auch eine
entsprechende Warnung ausgegeben. Leider kann ich nicht sagen, wie man
in der Arduino-IDE spezielle Compiler-Flags einschalten kann. Es soll
aber auf Umwegen gehen, wie ich irgendwo mal zufällig gelesen habe.
Rufus Τ. F. schrieb:> Das ist kein "Schrott Compiler", sondern legitimes C. Da darf eine> Variable gleichen Namens innerhalb eines Anweisungsblocks erneut> definiert werden und überblendet die Variable des äußeren Blocks. Diese> wird erst nach Verlassen des Blocks (und also Verlassen des "scopes", in> dem die innere Variable gültig ist und existiert) wieder sichtbar.
Hm, was wäre denn wohl ein sinnvoller Anwendungsfall für dieses Feature?
So auf Anhieb fällt mir keiner ein.
Patrick C. schrieb:> Die variable 'char buchstabe' ist 2x declarierthp-freund schrieb:>> char buchstabe>> Warum ist das in der Schleife? Wird buchstabe noch einmal definiert?> Meckert er nicht irgendwo?
Nein, er meckert nicht, aber DAS war das Problem! Vielen Dank an alle!
Gruss Chregu
Mark B. schrieb:> Hm, was wäre denn wohl ein sinnvoller Anwendungsfall für dieses Feature?> So auf Anhieb fällt mir keiner ein.
Modulares Programmieren. So eine temporäre Auto-Variable innerhalb einer
Funktion darf ruhig eine gleichnamige globale Variable, die in dem
konkreten Kontext aber irrelevant ist, "in den Schatten stellen".
Sonst müsste man als Programmierer ja alle Module, die dazugelinkt
werden, auf zufällig gleichnamige Variablen überprüfen.
Das gleiche gilt auch innerhalb von Funktionen, was bei Aufruf von
Makros, die temporäre Variablen verwenden, genauso sinnvoll ist.
Dann verstehe ich aber nicht, warum es mit Deklaration IN der Schleife
nicht funktioniert hat... (Do ... While ist (keine) Funktion?)
- Darf eine Variable nur einmal deklariert werden?
- Weil das "Do" vor der Deklaration steht?
Gruss Chregu
>> Dann verstehe ich aber nicht, warum es mit Deklaration IN der Schleife>> nicht funktioniert hat... (Do ... While ist (keine) Funktion?)
Weil das in der C standard so definiert ist
Einen link mit beispiel und bemerkungen (in English) :
http://www.geeksforgeeks.org/scope-rules-in-c/
Frank M. schrieb:> Modulares Programmieren. So eine temporäre Auto-Variable innerhalb einer> Funktion darf ruhig eine gleichnamige globale Variable, die in dem> konkreten Kontext aber irrelevant ist, "in den Schatten stellen".
Globale Variablen und modulare Programmierung ist freilich ein
Widerspruch in sich. Wenn ich von Letzterem möglichst viel haben will,
muss ich von Ersterem möglichst wenig haben.
Christian M. schrieb:> Dann verstehe ich aber nicht, warum es mit Deklaration IN der Schleife> nicht funktioniert hat... (Do ... While ist (keine) Funktion?)
Wie ich oben schon schrieb:
Im do-Block wird buchstabe als auto-Variable definiert, aber
außerhalb(!) des Blocks abgefragt.
Du arbeitest also im Block mit einer anderen Variable als bei der
Abfrage der Bedingung. Die Abfrage ist nämlich außerhalb des Blocks.
Mark B. schrieb:> Globale Variablen und modulare Programmierung ist freilich ein> Widerspruch in sich. Wenn ich von Letzterem möglichst viel haben will,> muss ich von Ersterem möglichst wenig haben.
"Möglichst wenig" schließt den Fall
Anzahl globaler Variablen > 0
nicht aus.
Es geht auch nicht nur um globale Variablen, sondern eher um den Scope
der Variablen. Wie gesagt, das Variable-Shadowing geht sogar innerhalb
einer Funktion. Bei Makros kann das sehr sinnvoll sein.
Christian M. schrieb:> Dann verstehe ich aber nicht, warum es mit Deklaration IN der Schleife> nicht funktioniert hat... (Do ... While ist (keine) Funktion?)
Nö, Do ... While ist keine Funktion, aber mit Funktionen hat es auch
nichts zutun.
> - Darf eine Variable nur einmal deklariert werden?
Innerhalb des selben Scopes darf eine Variable nur einmal definiert
werden, in verschiedenen Scopes kann man sie selbe Variable nicht
mehrfach definieren, weil es dann nichtmehr die selbe ist. Eine variable
mehrfach Deklarieren (mit extern) im globalen Scope sollte möglich sein.
> - Weil das "Do" vor der Deklaration steht?
Nö. Der scope ist immer durch die Darüberliegenden geschweifte Klammern
begrenzt, ausser die Variable wird im Schleifenkopf definiert. Bei for
und while ist Sie dann im Schleifenkopf & körper verfügbar, bei do while
nur im Schleifenkopf.
Daniel A. schrieb:> währe ja auch wahnsinn -Wshadow zu nutzen.
Im Normalfall schon, aber wenn man mal wie ein Blöder einen bestimmten
Fehler sucht, den man einfach nicht "packen" kann, darf man auch mal zu
ungewöhnlichen gcc-Optionen greifen. ;-)
Ich erinnere mich aber auch an einen C-Compiler unter UNIX SYSTEM V, der
das Shadowing grundsätzlich anmeckerte, ohne dass man überhaupt einen
bestimmten Warning-Level einschalten musste.
Rufus Τ. F. schrieb:> Das ist kein "Schrott Compiler", sondern legitimes C.
Du wirst aber zugeben, daß das gezeigte Stück Quelle ausgesprochener
Schrott ist.
Manchmal frag ich mich, warum die C-Programmierer so intensiv danach
trachten, möglichst grottenschlechten Code zu schreiben. Man hätte es ja
auch lesbarer und deutlich besser schreiben können, etwa so:
W.S. schrieb:> Manchmal frag ich mich, warum die C-Programmierer so intensiv danach> trachten, möglichst grottenschlechten Code zu schreiben.
C-Code wird halt oft von Elektrotechnikern geschrieben, und die wissen
es nicht besser ;-)
Mark B. schrieb:> W.S. schrieb:>> Manchmal frag ich mich, warum die C-Programmierer so intensiv danach>> trachten, möglichst grottenschlechten Code zu schreiben.>> C-Code wird halt oft von Elektrotechnikern geschrieben, und die wissen> es nicht besser ;-)
Informatiker verwenden nämlich lieber C++ ;-)
W.S. schrieb:> Du wirst aber zugeben, daß das gezeigte Stück Quelle ausgesprochener> Schrott ist.
Natürlich.
> Manchmal frag ich mich, warum die C-Programmierer so intensiv danach> trachten, möglichst grottenschlechten Code zu schreiben.
Tun sie nicht. Was Du hier an C-Code siehst, ist überwiegend
Anfängercode, oder Code, der von Anfängern aus Tutorials abgetippt
wurde.
> Man hätte es ja auch lesbarer und deutlich besser> schreiben können, etwa so:
Das ist auch nur Anfängercode, wenngleich dieser Anfänger etwas mehr
Erfahrung hat. Grauenerregende Formatierung, Benutzung von "magic
numbers", äußerst inkonsistente Verwendung von Whitespace, unnötiges und
die Leserlichkeit verschlechterndes Weglassen von Whitespace,
inkonsistente Bezeichnerschreibweise ...
Dirk B. schrieb:> Carl D. schrieb:>> Informatiker verwenden nämlich lieber C++ ;-)>> Und echte Programmierer ...
...können in jeder Sprache FORTRAN schreiben.
W.S. schrieb:> Man hätte es ja> auch lesbarer und deutlich besser schreiben können, etwa so:> if (c==10) return;
Lesbarer:
if (c == '\n') return;
> if (c==13)
Lesbarer:
if (c == '\r')
> if (c==8)
Lesbarer:
if (c == '\b')
> { Char_Out(8, wo);
Lesbarer:
{ Char_Out('\b', wo);
> Char_Out(c+0x40, wo);
Lesbarer:
Char_Out(c + 'A' - 1, wo);
> Kommandozeile[kzi] = 0;
Lesbarer:
Kommandozeile[kzi] = '\0';
Man muss nicht das ganze ASCII-Alphabet hexadezimal im Kopf haben, um in
C zu programmieren. Okay, es sieht natürlich kryptischer und damit
cooler aus... ;-)
Aber wegen dem Buzzword "lesbarer", welches Du oben schreibst, konnte
ich es mir nicht verkneifen, sorry.
Umraeumer schrieb:> Kaum entwirrt man die Struktur, springen die beiden dicken Bugs ins> Auge.
Ich weiß nicht, welche dicken Bugs Du meinst, aber diese Sachen fielen
mir schon vorher auf:
1
Kommandozeile[--kzi]=0;
Kein Check, ob kzi > 0. Mit der Backspace-Taste kann man daher schön im
RAM irgendwelche Zellen löschen.
Jedoch umgekehrt passt es:
1
if(kzi>=(sizeof(Kommandozeile)-1))// buffer full => ignore input
2
return;
Der darunterstehende Code wird also nur noch ausgeführt, wenn kzi
maximal 62 ist. Damit passt dann
1
Kommandozeile[kzi++]=c;
2
Kommandozeile[kzi]=0;
noch in den Buffer.
Warum er hier aber vorsichtshalber nochmal den String terminiert, obwohl
das
foo_clear(Kommandozeile, sizeof(Kommandozeile));
offenbar immer für den kompletten Buffer erledigt, weiß ich nicht.
Meines Erachtens ist die wiederholte Terminierung nach jedem Zeichen
überflüssig. Es würde eigentlich eine einmalige Terminierung bei Prüfung
auf '\r' reichen. Vorher wird der Buffer nämlich nirgendwo als String
interpretiert. Der foo_clear()-Aufruf kann dabei auch noch entfallen.
Dieses Verhalten kann man entweder als defensive Programmierung deuten
oder man liest einfach das Misstrauen des Autors in seine eigenen Zeilen
raus. Das ist jedem selbst überlassen.
Noch etwas ist mir aufgefallen:
Char_Out('^', wo);
Char_Out(c+0x40, wo);
Es werden zwei Zeichen für CTRL-Chars verwendet. Bei Backspace wird aber
nur ein Zeichen gelöscht. Das WYSIWYG-Prinzip wird daher verletzt: Die
aktuelle Ausgabe stimmt nicht mehr mit dem tatsächlichen Bufferinhalt
überein.
Aber wie gesagt: Das alles fiel mir schon vorher auf. Ich wollte jedoch
nicht den Code kaputtreden, sondern eher auf die Bezeichnung "lesbar"
eingehen.
Aber an diesem Beispiel sieht man, wieviel man innerhalb weniger
Code-Zeilen falsch machen kann.
Die Formulierung von W.S.
> Manchmal frag ich mich, warum die C-Programmierer so intensiv danach> trachten, möglichst grottenschlechten Code zu schreiben. Man hätte es ja> auch lesbarer und deutlich besser schreiben können, etwa so:
war daher eher ein Schuß nach hinten.
Umraeumer schrieb:> // achtung: viele returns, um else-Klammer-Orgien zu vermeiden. F#$K> MISRA
Es geht auch MISRA-conform, ohne returns oder großartige Klammer-Orgien:
Eric B. schrieb:> else if ((c == '\b')> && (kzi > 0)) // delete last char in buffer> {> Backspace_Out(wo);> Kommandozeile[--kzi]=0;> }> else if ((c != '\n')
Das ist von der Logik her falsch "übersetzt".
Wenn c == '\b' und gleichzeitig kzi == 0, dann läuft das Programm in den
else-Block unterhalb
> else if ((c != '\n')
und speichert dann das Backspace am Anfang des Buffers.
Richtig wäre:
1
elseif(c=='\b')
2
{
3
if(kzi>0))// delete last char in buffer
4
{
5
...
6
}
7
}
Nach demselben Muster ist das hier auch nicht schön, auch wenn es die
Logik hier ausnahmsweise nicht durcheinanderbringt:
1
elseif((c!='\n')// newline
2
&&(kzi<(sizeof(Kommandozeile)-1)))// buffer full
Hier sollte die 2. Bedingung auch in den else-if-Block. Du hast Glück,
dass dies nicht danebengeht, denn das liegt an dem leeren else-Block
darunter:
1
else
2
{
3
// do nix
4
}
Wäre da was drin, würde das irrtümlicherweise auch ausgeführt werden,
wenn c == '\n' und zufällig der Buffer voll ist.
Aber nix bleibt nix :-)
Eric B. schrieb:> Es geht auch MISRA-conform, ohne returns oder großartige Klammer-Orgien:
Natürlich. Ich persönlich finde es bei solchen langen Parsing-Ketten
lesbarer, wenn man gleich sieht, dass die Verarbeitung hier zuende ist,
ohne irgendwo weiter unten das Ende der Klammerebene zu suchen. Das ist
quasi-goto; in diesem Fall, wenn die Codestruktur sehr einem
Flussdiagramm entspricht, finde ich das völlig OK. Wenn Generationen von
Programmierern eine Funktion auf 1000 Zeilen aufgeblasen haben, sind
mehrere returns tödlich, aber dann hat man auch ganz andere Probleme.
Frank M. schrieb:> dann läuft das Programm in den> else-Block
Genau so etwas meinte ich. Geschachtelte else if sowie if()s, die
mehrere nicht direkt verwandte Dinge verknüpfen, sind in meiner Welt
viel böser als return mitten aus einer nicht übermäßig langen und
komplexen Funktion.
Umraeumer schrieb:> Geschachtelte else if sowie if()s, die> mehrere nicht direkt verwandte Dinge verknüpfen, sind in meiner Welt> viel böser als return mitten aus einer nicht übermäßig langen und> komplexen Funktion.
Das würde ich so pauschal nicht sagen. Eric B. hat einfach zu viele
Bedingungen in die else-if-Kette geschmissen.
Hätte er geschrieben:
1
if(c=='\r')// execute command and clear buffer
2
{
3
}
4
elseif(c=='\b')
5
{
6
// 2. Bedingung hier
7
}
8
elseif(c!='\n')// newline
9
{
10
// 2. Bedingung hier
11
}
wäre das durchaus lesbar und verständlich geblieben. Vor allen Dingen
wäre die Logik erhalten geblieben!
Nur ein Return am Ende der Funktion hat durchaus Vorteile: Wenn man am
Schluss nämlich nachträglich noch eine Aufräumaktion machen muss, dann
muss das nur einmal geschehen.
Ich hätte übrigens in einem zweiten Step dann obige else-if-Kette in
einen Switch gewandelt:
1
switch(c)
2
{
3
case'\r':
4
...
5
break;
6
case'\b':
7
...
8
break;
9
case'\n':
10
...
11
break;
12
default:
13
...
14
break;
15
}
Man kann also durchaus einfachen Code schreiben und trotzdem nur ein
Return am Ende der Funktion verwenden.
Moral von der Geschichte: Packe nicht zu viele Bedingungen in
if-else-if-Ketten. ;-)
Frank M. schrieb:> Es werden zwei Zeichen für CTRL-Chars verwendet. Bei Backspace wird aber> nur ein Zeichen gelöscht. Das WYSIWYG-Prinzip wird daher verletzt: Die> aktuelle Ausgabe stimmt nicht mehr mit dem tatsächlichen Bufferinhalt> überein.>> Aber wie gesagt: Das alles fiel mir schon vorher auf. Ich wollte jedoch> nicht den Code kaputtreden, sondern eher auf die Bezeichnung "lesbar"> eingehen.>> Aber an diesem Beispiel sieht man, wieviel man innerhalb weniger> Code-Zeilen falsch machen kann.>> Die Formulierung von W.S.> ...> war daher eher ein Schuß nach hinten.
Ach nö, du übertreibst mit Fleiß.
Guck dir nochmal den Eröffnungspost zum Vergleich an. Du wolltest ja
nicht auf Wasserdichtheit, sondern auf Lesbarkeit eingehen. Was mir
immer übel aufstößt, sind Formulierungen wie:
ist deutlich sauberer, da Deklaration und Verwendung getrennt sind - und
es verhindert auch, daß Leute wie der TO sich mit versehentlicher
Doppeldeklaration selbst ein Bein stellen. Rührt das daher, daß immer
einer vom anderen abkopiert ohne drüber nachzudenken?
Und was das const soll, möge Eric mal begründen.
Aber es ist für mich schon erstaunlich, was für einen Schwung an
Verbesserungsvorschlägen mein Post bewirkt hat..
Aber nochwas:
Deiner Behauptung, daß die Verwendung von \r und Konsorten lesbarer sei
als der ASCII-Wert, kann ich (zumindest für mich) nicht zustimmen. Ich
finde deine ganzen Backslash-Ausdrücke deutlich unleserlicher. Sowas
wird wohl nur von reinen C-Programmierern als angenehm empfunden.
W.S.
W.S. schrieb:> Deiner Behauptung, daß die Verwendung von \r und Konsorten lesbarer sei> als der ASCII-Wert, kann ich (zumindest für mich) nicht zustimmen.
Damit stehst Du aber ziemlich allein auf weiter Flur.
Rufus Τ. F. schrieb:> Damit stehst Du aber ziemlich allein auf weiter Flur.
Wie mit so vielen seiner Behauptungen, wenn es um C geht. Meine Favorit
bisher: In .h Dateien #include zu verwenden, sei generell schlechter
Stil. ;-)
Rufus Τ. F. schrieb:> Damit stehst Du aber ziemlich allein auf weiter Flur.
Ähem.. Tja, ist halt so - das kommt aber auf das Forum an.
Es gibt hier unter den C-Programmierern ne Menge Zeugs, was mir
ausgesprochen wider die Natur ist. Lassen wir das hier mal, sonst ufert
dieser Thread aus.
Aber mal zu sowas wie \xyz:
C kennt keinen Unterschied zwischen numerischen Elementen und
Textzeichen. Ein char ist zugleich Textzeichen und kleinstes numerisches
Element. Es ist deshalb was völlig Normales, mit char's mit numerischen
Werten zu benützen - egal ob dezimal, oktal oder hexa oder sonstwie. Von
Pascal her kennt man so ein Zusammenwurschteln nicht, da sind beide
Sphären (Text versus Zahlen) sauber voneinander getrennt - jedenfalls
logisch. Nun denn, bei C hat man das nicht, geht ja auch.
Aber mal ne Frage: Wie kommt ihr auf sowas wie '\r' eigentlich? Nun,
das ist eine Konvention, die man auch mal wieder auswendig lernen muß.
Eben NOCH EINE zum Auswendiglernen. Aber logisch ist sie nicht, denn
dann müßte man für ASCII-Zeichen < Leerzeichen eher '\Großbuchstabe
schreiben, also für CR eben '\M' was ('M' & 0x1F) entsprechen würde. Das
wäre logisch, '\r' ist es nicht.
Oder anders gefragt, wie würdet ihr STX, VT, RS, BEL oder ACK auf
logische Weise mit '\???' schreiben? jaja: nachgucken, ob's überhaupt
geht.
Mir für meinen Teil ist es viel einfacher, auf solche Konventionen zu
pfeifen und den tatsächlichen numerischen ASCII-Wert hinzuschreiben. Wer
das nicht versteht, muß eben in seine ASCII-Tafel gucken - aber bei '\c'
und seinen eher seltener verwendeten Konsorten müßte er ebenso
nachschauen, was zum Teufel das nun wieder bedeuten soll. Die \r und \n
sind ja nur die allerhäufigsten, ebenso wie 13 und 10.
Soviel zum Thema Lesbarkeit.
W.S.
W.S. schrieb:> Aber mal ne Frage: Wie kommt ihr auf sowas wie '\r' eigentlich? Nun,> das ist eine Konvention, die man auch mal wieder auswendig lernen muß.
Und wenn man es einmal angesehen hat, weiss man es. Aber 13 wird man
nächstes mal wieder vergessen haben.
Und wie kommt man drauf:
\n - n ewline
\r - r etuen
\b - b ackspace
\t - t ab(ulator)
\v - v ertical tabulator
\e - e scape
\a - a lert
Intuitiv und Verwechslungssicher, oder?
Ausserdem: Sobald du einen Wert grösser als 127 eingeben müsstest,
könnte ein char signed oder unsigned sein, dan hat dein Code eine 50%
Chance eine Overflow Warnung zu generieren.
W.S. schrieb:> C kennt keinen Unterschied zwischen numerischen Elementen und> Textzeichen. Ein char ist zugleich Textzeichen und kleinstes numerisches> Element.
Bis hier ist noch alles richtig.
> Es ist deshalb was völlig Normales, mit char's mit numerischen> Werten zu benützen
Das ist aber falsch. Es ist nicht anormal signed char oder /unsigned
char/ für Zahlen zu verwenden, aber "char" ist dafür ungeeignet.
Umgekehrt verwendet man für Zeichen char, und nicht signed char oder
unsigned char.
W.S. schrieb:> Eben NOCH EINE zum Auswendiglernen.
Wo Du doch gegen Auswendiglernen bist: Dafür weisst Du aber verdammt
gut, dass 'A' == 0x41 ist. Deshalb addierst Du zur Darstellung von
Steuerzeichen ja lieber 0x40 statt 'A' - 1.
Warum schreibst Du dann nicht 'A' - 1? Schließlich geht es ja um die
Darstellung von ^A bis ^Z. Wohlgemerkt: Bis ^Z. Die Zeichen von 26 bis
31 fehlen auch noch ;-)
Das (und die anderen verwendeten Hex-Zahlen) zeigen mir eher, dass Du
das ganze ASCII-Alphabet auswendiggelernt hast. Deine ganze
Argumentation hast Du doch durch Deinen eigenen (zudem fehlerhaften)
Codeschnipsel selbst widerlegt.
P.S.
Im Laufe der Jahre habe ich das ASCII-Alphabet auch auswendiggelernt.
Aber deshalb käme ich nie auf die Idee, für z.B. 'D' besser 0x44 zu
schreiben. Genauso halte ich es mit \n, \r, \t usw. Wie Daniel schon
schrieb: Jeder Buchstabe hat eine Bedeutung, die man sich sehr einfach
merken kann. Das ist wesentlich intuitiver - und deshalb auch lesbarer.
Rufus Τ. F. schrieb:>> Deiner Behauptung, daß die Verwendung von \r und Konsorten lesbarer sei>> als der ASCII-Wert, kann ich (zumindest für mich) nicht zustimmen.>> Damit stehst Du aber ziemlich allein auf weiter Flur.
Hängt warscheinlich auch noch mit dem Alter zusammen. Diese
Backslash-Ausdrücke tauchten Gefühlsmässig eher in jüngerer Zeit auf.
Mir persönlich ist CR/LF und 0dh/0ah deutlich geläufiger.
Gruss Chregu
W.S. schrieb:> ...da Deklaration und Verwendung getrennt sind - und> es verhindert auch, daß Leute wie der TO sich mit versehentlicher> Doppeldeklaration selbst ein Bein stellen.
Das Problem ist veilleicht deswegen, weil es überhaupt möglich ist, mit
der Deklaration gleich einen Wert zuzuweisen. Gefahr besteht: Ich brauch
schnell ne Variable, will nicht raufscrollen, also deklarier ich sie
schnell vor Ort. In anderen Programmiersprachen halte ich konsequent
Ordung, in C sind dies meine ersten Schritte...
Gruss Chregu
Daniel A. schrieb:> Und wie kommt man drauf:> \n - n ewline> \r - r etuen> \b - b ackspace> \t - t ab(ulator)> \v - v ertical tabulator> \e - e scape> \a - a lert>> Intuitiv und Verwechslungssicher, oder?
und passt auch für EBCDIC, genau wie 'A' - 1
MfG Klaus
Christian M. schrieb:> Hängt warscheinlich auch noch mit dem Alter zusammen.
Ich verdiene mein Geld seit bald 30 Jahren mit C und artverwandtem, da
bin ich vermutlich noch zu jung ...
Christian M. schrieb:> Hängt warscheinlich auch noch mit dem Alter zusammen. Diese> Backslash-Ausdrücke tauchten Gefühlsmässig eher in jüngerer Zeit auf.
Abschrift aus K&R, 1978, Seite 6 ziemlich oben
> main()> {> printf("hello, world\n");> }
MfG Klaus
Rufus Τ. F. schrieb:> Ich verdiene mein Geld seit bald 30 Jahren mit C und artverwandtem, da> bin ich vermutlich noch zu jung ...
Respekt. Wie kann ein einzelner Mann ein so hartes Schicksal über so
eine lange Zeit ertragen, ohne sich dem Suff zu ergeben?
;-)
MfG Paul
Klaus schrieb:> Abschrift aus K&R, 1978, Seite 6 ziemlich oben
Mit dem Mistbuch habe ich meine ersten (damals nicht sehr erfolgreichen)
C-Versuche unternommen. Glücklicherweise kam dann recht schnell die
zweite Ausgabe heraus, und mit Borlands "Turbo-C 2.0" (in .de von
Heimsoeth vertrieben, mit von Arne Schäpers komplett neu geschriebenen
Handbüchern), und da wurde es schlagartig viel, viel besser. Das war
'89/'90.
Christian M. schrieb:> Das Problem ist veilleicht deswegen, weil es überhaupt möglich ist..
ja, sehe ich auch so.
Aber ich meine, es steckt mehr dahinter, nämlich falsches Anlernen.
C ist keine logische Sprache, sondern eher eine diktatorische, wo es
heißt "das ist hier so, also lerne das auswendig!" und deshalb wird auch
relativ sklavisch auf Beispiele als Vorbilder geschaut und nachgemacht.
So pflanzt sich das fort und nach einiger Zeit ist allen C-Schülern
klar: "Das MUSS so gemacht werden, es hinterfragen zu wollen bringt
nix."
Daniel A. schrieb:> Intuitiv und Verwechslungssicher, oder?
Nö. Beides nicht, sondern genauso gewöhnungsbedürftig wie alles andere
einschließlich ASCII.
Daniel A. schrieb:> Das ist aber falsch. Es ist nicht anormal signed char oder /unsigned> char/ für Zahlen zu verwenden, aber "char" ist dafür ungeeignet.> Umgekehrt verwendet man für Zeichen char, und nicht signed char oder> unsigned char.
Dir fehlt der Überblick. signed oder unsigned sind lediglich Attribute
zum char - genauso wie short und long für's int. Der char ist das 8
bittige Grundelement. Oder anders formuliert: es fehlt das byte im
numerischen und die strikte Trennung zu Textzeichen. In Pascal könntest
du so nicht argumentieren, auch nicht bei den meisten Assemblern.
Also Leute, es ist mittlerweile wohl klar genug geworden, daß sowas wie
\c und Konsorten nur von solchen Leuten als intuitiver angesehen wird,
die erstens ziemlich reine Programmierer sind und zweitens außer C und
C-artigen Programiersprachen nichts verwenden resp. mehr kennen. Ist
halt mittlerweile ne Monokultur geworden und das ist aus prinzipiellen
Gründen ganz sauschlecht, wenngleich sowas auch für's Tagesgeschäft als
zweitrangig angesehen wird.
Rufus Τ. F. schrieb:> Ich verdiene mein Geld seit bald 30 Jahren mit C und artverwandtem,
Soll man "artverwandt" jetzt als C++, C#, Java auffassen? Mir geht es
so, daß ich jedesmal wieder ne Krise kriege, wenn ich von Pascal (also
Delphi) in die C-Gefilde runter muß. Aber ich verdiene meine Brötchen
auch nicht mit Software, sondern mit allem zusammen, also HW+SW.
W.S.
Ich habe, als ich den ersten brauchbaren C-Compiler in die Hände bekam,
mich mit Freude von Pascal & Co. verabschiedet. Das sind Sprachen, die
dafür erfunden wurde, anderen Leuten das Programmieren beizubringen,
aber nicht, um tatsächlich darin zu programmieren.
@Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
>Ich habe, als ich den ersten brauchbaren C-Compiler in die Hände bekam,>mich mit Freude von Pascal & Co. verabschiedet. Das sind Sprachen, die>dafür erfunden wurde, anderen Leuten das Programmieren beizubringen,>aber nicht, um tatsächlich darin zu programmieren.
Na wenn DAS mal kein Fehdehandschuh ist!!!
Wofür ist denn dann C gedacht? Für Leute, die sich gern beim
Programmieren in den Fuß schießen? Oder die sich lieber mit dem
Rasiermesser rasieren anstatt (Sicherheits)rasierklingen zu nutzen? So
wie echte Männer. Naja fast, die echten programmieren immer noch in ASM
;-)
C hat sich nicht wegen seiner überragenden Vorteile durchgesetzt, eher
wegen seines Pragmatismus und einer gehörigen Portion Rüpelhaftigkeit
;-)
Falk B. schrieb:> Wofür ist denn dann C gedacht? Für Leute, die sich gern beim> Programmieren in den Fuß schießen? Oder die sich lieber mit dem> Rasiermesser rasieren anstatt (Sicherheits)rasierklingen zu nutzen? So> wie echte Männer.
Wenn das der Grund für die große Verbreitung von C wäre, würde sich ein
Großteil der Männer mit dem Messer rasieren, was aber definitiv nicht
der Fall ist.
Ein passenderer Vergleich wäre IMHO:
C = normales Fahrrad
Pascal = Fahrrad mit Stützrädern
Ein Fahrrad mit Stützrädern hat zugegebenermaßen zwei entscheidende
Vorteile:
- Es erleichtert Anfängern den Einstieg ins Radfahren.
- Es verringert die Gefahr von Stürzen.
Genau diese beiden Kriterien (übertragen auf die Softwaretechnik)
standen bei der Entwicklung von Pascal im Vordergrund. Dass eber die
meisten Leute beim Radfahren trotzdem auf Stützräder verzichten, hängt
sicher nicht nur mit dem Herdentrieb zusammen.
> Naja fast, die echten programmieren immer noch in ASM> ;-)
Eben. Zu den Asm-Programmierern passt der Vergleich mit den
Messerrasierern auch viel besser :)
Yalu X. schrieb:> Ein passenderer Vergleich wäre IMHO:>> C = normales Fahrrad>> Pascal = Fahrrad mit Stützrädern
Ich habe einen anderen Eindruck:
Pascal-> komfortables Fahrrad mit bequemem Sattel, Nabenschaltung
C-> blanker Rahmen ohne Sattel mit Stummellenker ohne Rücktritt und
Felgenbremse
Dieser Mist hat sich nicht durchgesetzt -er ist durchgesetzt worden.
MfG Paul
@ Paul Baumann (paul_baumann)
>Pascal-> komfortables Fahrrad mit bequemem Sattel, Nabenschaltung>C-> blanker Rahmen ohne Sattel mit Stummellenker ohne Rücktritt und>Felgenbremse
;-)
>Dieser Mist hat sich nicht durchgesetzt -er ist durchgesetzt worden.
Nein, denn dort hatte der Ostblock mit seinen Strukturen nichts zu
melden, die haben nur kopiert und nachgebaut. Vielmehr sind viele
Programmierer damals wie heute eher schlampige Pragmatiker mit einem
GUTEN Schuß Chaos! Da war das sichere Pascal halt zu langweilig.
Das Pascal der 70er war als Lehrsprache entwickelt und in dieser Form
sonst nur schlecht zu gebrauchen. Der Wirth'sche Ansatz eben. So hatte
er es später auch gehalten und hat je nachdem womit er sich grad
rumschlug auch eine Sprache dazu erschaffen.
Das damalige C hingegen liess sich trotz aller Mängel auch darüber
hinaus verwenden. Und es sparte Ressourcen, sowohl im Rechner als auch
im Budget, denn es war bei Unix stets dabei und die PDP-11er dazu fanden
sich an Universitäten öfter. Es gab einen Standard dazu, und einen
relativ leicht auf verschiedene Architekturen portierbaren Compiler (den
Portable C Compiler).
C hat sich nicht aufgrund irgendwelcher sprachlicher Qualitäten
durchgesetzt, sondern weil es in leidlich brauchbarer Form zur richtigen
Zeit im richtigen Marktsegment maschinenübergreifend vorhanden und
einsetzbar war.
Pascal hatte eine Blüte in Form des ziemlich genialen Turbo-Pascal, erst
CP/M dann DOS. Aber das blieb eine Insel. Andere Rechner, klein wie
gross, hatten entweder ein ziemlich anderes Pascal (ggf. per
Bytecode-Interpreter), oder überhaupt keines.
A. K. schrieb:> Das Pascal der 70er war als Lehrsprache entwickelt und in dieser Form> sonst nur schlecht zu gebrauchen.
Die EDV eines ganzen Kombinates wurde NUR mit Pascal-Programmen
bewerkstelligt. Warum? Weil dise Programme vorher in Algol geschrieben
waren und sich ohne großen Sackgang in Pascal-Quelltext umsetzen ließen.
Darüber hinaus waren sehr wenige Kommentare im Quelltext nötig, weil er
an sich schon selbst erklärend war. So waren kleine Änderungen und/oder
Zusätze schnell zu machen, wenn Irgendeiner z.B. die Arbeitskräfte nach
Alter sortiert haben wollte.
MfG Paul
Die erste brauchbare C-Version (C89, "ANSI-C") gab es auch erst
zeitgleich mit dem Ende der DDR; wäre C nicht über den Stand des älteren
K&R-C hinausgekommen, sähe die Softwarewelt vermutlich deutlich anders
aus.
Paul B. schrieb:> Ich habe einen anderen Eindruck:> Pascal-> komfortables Fahrrad mit bequemem Sattel, Nabenschaltung> C-> blanker Rahmen ohne Sattel mit Stummellenker ohne Rücktritt und> Felgenbremse>> Dieser Mist hat sich nicht durchgesetzt -er ist durchgesetzt worden.
Wilde Verschwörungstheorien? ;-)
Paul B. schrieb:> Darüber hinaus waren sehr wenige Kommentare im Quelltext nötig, weil er> an sich schon selbst erklärend war.
Quellcode ist niemals von alleine selbsterklärend. Denn wohl jede
Programmiersprache kennt mehr oder weniger beliebig wählbare Bezeichner
für Variablen und Funktionen. Wer seine Variablen a, b, c nennt und
seine Funktionen d, e, f dem ist in keiner Sprache der Welt zu helfen.
Mark B. schrieb:> Quellcode ist niemals von alleine selbsterklärend.
Ach?! Das legt Mark Brandis per Definition fest, oder wie?
> Denn wohl jede> Programmiersprache kennt mehr oder weniger beliebig wählbare Bezeichner> für Variablen und Funktionen. Wer seine Variablen a, b, c nennt und> seine Funktionen d, e, f dem ist in keiner Sprache der Welt zu helfen.
Ist heute DDR-Meisterschaft im Binsen-Weisheit-Heraushauen?
Verschone mich mit so einem Sülz. Bleib bei "Ausbildung und Beruf" mit
Deinen Weisheiten.
MfG Paul
Paul B. schrieb:> Mark B. schrieb:>> Quellcode ist niemals von alleine selbsterklärend.>> Ach?! Das legt Mark Brandis per Definition fest, oder wie?
Jeder, der ein paar Jahre Berufserfahrung hat, weiß was ich meine.
Es gibt Programmierer, die einigermaßen selbsterklärenden Code schreiben
können. Das ist aber nun mal eine Eigenschaft des Bearbeiters, und nicht
etwa der Programmiersprache.
Es gilt nach wie vor:
"Man kann in jeder Programmiersprache schlechten Code schreiben."
Diese Aussagen habe ich nicht erfunden. Aber es ist einfach so.
Paul B. schrieb:> Ist heute DDR-Meisterschaft im Binsen-Weisheit-Heraushauen?>> Verschone mich mit so einem Sülz. Bleib bei "Ausbildung und Beruf" mit> Deinen Weisheiten.
Ja so ist der Paul. Immer große Sprüche raushauen, aber wenn ihm mal
einer widerspricht, wird er sofort pampig. Ziemlich kindisch...
Da D. schrieb:> Ja so ist der Paul.
Richtig erkannt: So ist Paul. Widerpart geben, wenn ihm Einer vom Pferd
erzählt werden soll.
> Immer große Sprüche raushauen, aber wenn ihm mal> einer widerspricht, wird er sofort pampig.
Nicht sofort. Nur dann, wenn ein notorischer Rechthaber seine
Plattitüden und Binsenweisheiten bringt.
> Ziemlich kindisch...
Da zitiere ich mal Dittsche: Deine Ansicht bleibt Dir unbenommen.
-Paul-
Es ist wirklich selten, daß ich Mark zustimmen kann, aber hier hat er
tatsächlich recht.
Miesen unwartbaren Quelltext kann man in jeder Programmiersprache
schreiben.
Rufus Τ. F. schrieb:> Es ist wirklich selten, daß ich Mark zustimmen kann, aber hier hat er> tatsächlich recht.>> Miesen unwartbaren Quelltext kann man in jeder Programmiersprache> schreiben.
Das ist doch überhaupt nicht der Punkt, um den es geht. Mark
unterstellt, daß die Quelltexte von denen ich sprach, nicht
selbsterklärend wären.
Die Leute, die diese Programme schrieben, waren aber durchaus in der
Lage, Variablennamen zu vergeben, die den Inhalt erklärten -eben nicht
a,b oder c.
Gut, das war die Zeit, in der man noch miteinander arbeitete -nicht
wie heute gegeneinander. Da war man so klug, die Programme so zu
schreiben, daß ein anderer Programmierer sofort am Quelltext
weiterarbeiten konnte.
Heute versucht sich jeder Drecksack mit unleserlichem Code unentbehrlich
zu machen und ist darauf auch noch stolz wie Bolle. Das ist eine
Einstellung, die ich in meinem Leben nicht mehr gutheißen werde.
-Paul-
Paul B. schrieb:> Das ist doch überhaupt nicht der Punkt, um den es geht. Mark> unterstellt, daß die Quelltexte von denen ich sprach, nicht> selbsterklärend wären.
Du musst schon auch richtig lesen wollen. Ich habe wörtlich geschrieben:
Mark B. schrieb:> Quellcode ist niemals von alleine selbsterklärend.
Diese Aussage ist korrekt. Sie impliziert: "Quellcode ist dann
selbsterklärend, wenn er von einem fähigen Bearbeiter so geschrieben
wurde. Also nicht von allein".
Die Möglichkeit, dass die von Dir erwähnten Quelltexte von guter
Qualität waren, wird durch meine Aussage in keinster Weise verneint.
Vielleicht mit dem falschen Fuß aufgestanden heute?
Paul B. schrieb:> Heute versucht sich jeder Drecksack mit unleserlichem Code unentbehrlich> zu machen und ist darauf auch noch stolz wie Bolle. Das ist eine> Einstellung, die ich in meinem Leben nicht mehr gutheißen werde.
Hier stimme ich Dir weitgehend zu.
Freilich ist es auch ein Versagen der Firmen, die solchen Code von ihren
Mitarbeitern akzeptieren. Wer keine Maßstäbe für Qualität aufstellt und
diese anwendet, der hat eben auch keine Qualität.
Somit gibt es im Fall von schlechtem Code (und der kommt leider wirklich
oft vor) mehr als einen Schuldigen.
Paul, die Probleme in der Softwareentwicklung haben sich in den letzten
30 Jahren etwas geändert:
- Damals war ein 5000-Zeilen-Programm schon überdurchschnittlich groß.
Heute fangen komplexe Programme bei 100000 Zeilen an, und auch mehrere
Millionen Zeilen sind keine Seltenheit. Das hängt damit zusammen, dass
die heutigen Computer wesentlich leistungsfähiger sind, und der
Benutzer erwartet, dass diese Leistungsfähigkeit zur Steigerung der
Funktionalität und Benutzerfreundlichkeit auch tatsächlich genutzt
wird.
- Ein Programm, das einen gestandenen Entwickler damals ordentlich
herausgefordert hat, schreibt heute ein engagierter Schüler in
kürzerer Zeit und in besserer Qulität. Das liegt aber nicht daran,
dass die Leute heute gescheiter sind, sondern daran, dass sie heute
die Möglichkeit haben, sich bereits in jungen Jahren in die Materie
einzuarbeiten und dabei im Gegensatz zu damals auf einen riesigen Pool
mit Informationen und vorgefertigten Teillösungen zugreifen können.
Damit werden die großen Probleme von damals zu kleinen Problemen
heute. Die wahren Probleme von heute hingegen waren damals noch
weitgehend unbekannt (s. folgende Punkte).
- Damals war das größte Problem bei der Analyse eines fremden Programms,
die darin verwendeten Algorithmen zu verstehen. Das ist heute zwar oft
immer noch ein Problem, viel schwieriger ist es aber in vielen Fällen,
die Gesamtstruktur eines großen Programms zu erfassen. Beides ist
i.Allg. nur mit einer entsprechenden Programmdokumentation zu
erschlagen. Für die Erläuterungen einfacher Algorithmen genügen meist
Quelltextkommentare, komplexe Algorithmen und Softwarestrukturen
erfordern oft aber auch eine externe Dokumentation mit viel Text und
Grafiken, die man nicht mehr im Quelltext unterbringen kann.
- Gerade die Wartbarkeit und Erweiterbarkeit von komplexen Programmen
erfordern heute geeignete Softwarestrukturen, die ein Programm für
einen Unerfahrenen noch komplexer erscheinen lassen, als es ohnehin
schon ist. Wer diese Strukturen aber verstanden hat, wird sich bei
seinen Vorentwicklern dafür bedanken.
- Bis zu einer gewissen Größe konnten und können Quellcodepassagen
durchaus auch selbsterklärend geschrieben werden. Der Unterschied
zwischen damals und heute: Damals konnte man in diesem Größenlimit
fast ein gesamtes typisches Programm unterbringen, bei den heutigen
komplexen Programmen nur noch kleine Bruchteile davon.
- Damals war es bzgl. der Lesbarkeit vielleicht noch ein Unterschied, ob
eine Variable x wie in Pascal mit inc(x) oder wie in C mit ++x
inkrementiert wird, heute treten solche Miniproblemchen, die sich
innerhalb einer Codezeile abspielen, völlig in den Hintergrund. Es
wird einfach erwartet, dass ein Programmierer die von ihm verwendete
Sprache beherrscht. Wer über solche Kleinigkeiten stolpert und meint,
alleine durch Intuition programmieren zu können und deswegen eine
Programmiersprache nicht richtig lernen zu müssen, hat heute in der
ernsthaften Softwareentwicklung nichts mehr zu suchen.
Paul B. schrieb:> Gut, das war die Zeit, in der man noch miteinander arbeitete -nicht> wie heute gegeneinander. Da war man so klug, die Programme so zu> schreiben, daß ein anderer Programmierer sofort am Quelltext> weiterarbeiten konnte.
Ich mache selber viel Software und arbeite auch mit vielen anderen
Softwarentwicklern (teilweise von mehreren verschiedenen Firmen)
zusammen. Deine Aussage kann ich aber überhaupt nicht bestätigen.
Geschätzt 95% der Softwareentwickler, die ich kenne, sind sehr
kooperativ. Von den restlichen 5%, die den Entwicklungsprozess mitunter
etwas behindern, tun dies praktisch alle nicht bewusst und absichtlich,
sondern auf Grund mangelder Erfahrung.
Paul B. schrieb:> Heute versucht sich jeder Drecksack mit unleserlichem Code unentbehrlich> zu machen und ist darauf auch noch stolz wie Bolle.
Die "Drecksäcke", wie du sie nennst, haben das früher genauso getan,
sonst würde man sie ja nicht mit diesem bösen Ausdruck beschimpfen :)
Paul B. schrieb:> Dieser Mist hat sich nicht durchgesetzt -er ist durchgesetzt worden.Rufus Τ. F. schrieb:> Ich habe, als ich den ersten brauchbaren C-Compiler in die Hände bekam,> mich mit Freude von Pascal & Co. verabschiedet.
Genauso wie Rufus erging es auch mir.
Ich lernte zuerst Basic. Nachdem ich meine ersten Pascal-Erfahrungen
gemacht hatte war ich so begeistert, dass ich Basic links liegen ließ.
Irgendwann fing ich (wohlbemerkt freiwillig) mit C an und war noch mehr
begeistert. Seither verwende ich Pascal nur noch ganz selten, und dann
ausschließlich aus nostalgischen Gründen ;-)
Das heißt jetzt aber überhaupt nicht, dass C für mich die Königin aller
Programmiersprachen ist, dafür hat C viel zu viele Macken. Aber in
vielen Anwendungsfällen ist C für mich trotz seines hohen Alters nach
wie vor das bestgeignete Werkzeug.
@Yalu
Ich bedanke mich zunächst mal für die Mühe, die Du Dir mit Deinem recht
langen Text gemacht hast -insbesondere dafür, daß Du nicht nur einzelne
Bröckchen aus meinem Beitrag extrahiert hast.
Ich begann das Programmieren mit der Sprache Algol60 und danach
wechselte ich auf Pascal, was ich beibehalten konnte, da es sowohl auf
den Rechnern der Arbeitsstelle als auch auf meinem (Eigenbau)-Rechner
unter CP/M bzw.
SCP lauffähig war und ich alle meine Sachen damit erledigen konnte.
Heute gehe ich mit Purebasic auf dem Rechner an's Werk, weil das schöne
kleine Programme ohne irgendwelchen Anhang zum Mitschleppen erzeugen
kann.
Zum Programmieren von AVR-Kontrollern (Andere nehme ich für meine Zwecke
nicht) gehe ich mit Bascom an's Werk, wobei man dort auch Assembler mit
einfügen kann.
C habe ich versucht, mir beizubringen -wenigstens soweit, daß ich den
Algorithmus in Quelltexten Anderer erkennen kann. Trotzdem gehe ich mit
Zittern und Zagen dran, aber -ich muss ja auch nicht. In diesem Sinne:
Gut Holz und Waidmannsheil den C-Anhängern.
MfG Paul
@Yalu X. (yalu) (Moderator)
>Paul, die Probleme in der Softwareentwicklung haben sich in den letzten>30 Jahren etwas geändert:
Schöner Text, Danke!
>Das heißt jetzt aber überhaupt nicht, dass C für mich die Königin aller>Programmiersprachen ist, dafür hat C viel zu viele Macken. Aber in>vielen Anwendungsfällen ist C für mich trotz seines hohen Alters nach>wie vor das bestgeignete Werkzeug.
Es ist der Engländer im Softwarewerkzeugkasten ;-)
https://de.wikipedia.org/wiki/Engl%C3%A4nder_%28Werkzeug%29
Daniel A. schrieb:> 13 wird man> nächstes mal wieder vergessen haben.
Nö !!
Die wichtigsten ASCII-Codes sollte ein Programmierer schon kennen. Aber
das geht ja hier nicht, dann müßte man ja Magic-Numbers schreiben - Pfui
Teufel. Diese bekloppten Escapesequenzen kann sich keine Sau merken und
man muß diese immer wieder nachschauen. Das ist auch so eine Unart von C
und C ähnlichen Sprachen.
Christian M. schrieb:> Das Problem ist veilleicht deswegen, weil es überhaupt möglich ist, mit> der Deklaration gleich einen Wert zuzuweisen. Gefahr besteht: Ich brauch> schnell ne Variable, will nicht raufscrollen, also deklarier ich sie> schnell vor Ort. In anderen Programmiersprachen halte ich konsequent> Ordung, in C sind dies meine ersten Schritte...
Ja genau das sind die Stolpersteine in C und Konsorten.
Genau solche Features von C verleiten dazu unstrukturierten und
fehlerträchtigen (im Sinne von nicht wie gewünscht funktionierend) Code
zu schreiben.
Allerdings kann man auch in C durchaus gut strukturierten und
leserlichen Code schreiben, wenn man will - es gibt viele C-Programierer
die die beweisen aber eben auch sehr viele denen dies zu mühselig ist.
Rufus Τ. F. schrieb:> Das sind Sprachen, die> dafür erfunden wurde, anderen Leuten das Programmieren beizubringen,> aber nicht, um tatsächlich darin zu programmieren.
Oh!!
Die Arroganz kennt keine Grenzen.
Falk B. schrieb:> C hat sich nicht wegen seiner überragenden Vorteile durchgesetzt, eher> wegen seines Pragmatismus und einer gehörigen Portion Rüpelhaftigkeit> ;-)
Richtig!
Yalu X. schrieb:> Ein passenderer Vergleich wäre IMHO:>> C = normales Fahrrad>> Pascal = Fahrrad mit Stützrädern
Noch so ein arroganter Rüpel.
Paul B. schrieb:> Heute versucht sich jeder Drecksack mit unleserlichem Code unentbehrlich> zu machen und ist darauf auch noch stolz wie Bolle. Das ist eine> Einstellung, die ich in meinem Leben nicht mehr gutheißen werde.
Du wirst mir immer sympathischer.
Paul B. schrieb:> Heute versucht sich jeder Drecksack mit unleserlichem Code unentbehrlich> zu machen und ist darauf auch noch stolz wie Bolle. Das ist eine> Einstellung, die ich in meinem Leben nicht mehr gutheißen werde.
Du wirst mir immer sympathischer.
Yalu X. schrieb:> Ein Programm, das einen gestandenen Entwickler damals ordentlich> herausgefordert hat, schreibt heute ein engagierter Schüler in> kürzerer Zeit und in besserer Qulität.
Das sieht man den heutigen Programmen auch an.
Yalu X. schrieb:> Ich mache selber viel Software und arbeite auch mit vielen anderen> Softwarentwicklern (teilweise von mehreren verschiedenen Firmen)> zusammen. Deine Aussage kann ich aber überhaupt nicht bestätigen.> Geschätzt 95% der Softwareentwickler, die ich kenne, sind sehr> kooperativ. Von den restlichen 5%, die den Entwicklungsprozess mitunter> etwas behindern, tun dies praktisch alle nicht bewusst und absichtlich,> sondern auf Grund mangelder Erfahrung.
Arbeitest Du im Software-Schlaraffenland? Ich kann Pauls Aussage nur
bestätigen.
Yalu X. schrieb:> Aber in> vielen Anwendungsfällen ist C für mich trotz seines hohen Alters nach> wie vor das bestgeignete Werkzeug.
Ich meine wir sind hier in µC-Forum und leider gibt es für µC nichts
Anderes. Wenn es einen vernünftigen Pascalcompiler für µC geben würde,
dann würde ich keine Sekunde mehr mit C verschwenden.
Im übrigen hat sich Pascal auch weiter entwickelt und es kann nicht mehr
mit dem Pascal der 80'ziger und 90'ziger verglichen werden.
Zeno schrieb:> Noch so ein arroganter Rüpel.
Der Yalu? Nicht Dein Ernst.
Wenn Du hier regelmäßig liest, dann wirst Du feststellen dass seine und
Karl-Heinz Bucheggers Beiträge mit zum Besten gehören, was Du hier auf
mikrocontroller.net vorfinden kannst.
Rufus Τ. F. schrieb:> Die erste brauchbare C-Version (C89, "ANSI-C") gab es auch erst> zeitgleich mit dem Ende der DDR;
Die K&R Version der Sprache hatte klare Mängel und auch offene Punkte,
war aber offensichtlich brauchbar. Zumindest aus damaliger Sicht (bitte
keine Kommentare über etwaige Parallelen zur DDR ;-). Komplette
Unix-Systeme sind damit entstanden. Mitsamt X11 und Anwendungen.
Zeno schrieb:> Allerdings kann man auch in C durchaus gut strukturierten und> leserlichen Code schreiben, wenn man will
Eben - es geht. Setzt aber eine gewisse Portion von Motivation und
Intelligenz voraus.
> - es gibt viele C-Programierer> die die beweisen aber eben auch sehr viele denen dies zu mühselig ist.
Nicht jeder ist für C geschaffen. Ohne Brain 1.0 wird das einfach nix. C
ist keine Programmiersprache für Leute, die ab und zu mal ein
Progrämmchen schreiben. Auch nach vielen Jahren lernt man als
C-Programmierer noch dazu. Wenn man sich intensiv mit C beschäftigt,
dann wird man irgendwann auch belohnt. Ist halt harte Arbeit und nix für
Prinzessinnen auf der Erbse. Für diese gibt es andere
Programmiersprachen (Pascal, Basic etc.), mit denen sie aber auch dort
nicht so weit kommen werden, wie sie eigentlich wollten, sondern ab
einer bestimmten Entwicklungsstufe einfach steckenbleiben.
Ohne Fleiß keinen Preis!
Von daher betrachte ich solche Schimpftiraden auf C lediglich als
Ausdruck eines gewissen Frustes, der auftritt, wenn man sich nur
oberflächlich mit C beschäftigt. Oberflächlich deshalb, weil derjenige
meinst, mit möglichst wenig Einsatz möglichst viel zu erreichen. Das ist
mit C aber nicht möglich, denn es erfordert eine sehr intensive
Beschäftigung mit der Programmiersprache.
Wenn jemand dermaßen auf C schimpft, soll er:
- einfach eine eigene Programmiersprache erfinden
- sich eine andere Programmiersprache suchen
- sich damit abfinden, dass er mit anderen Sprachen nicht
soviel erreichen kann, wir er sich erhofft hat
- einfach mal die Klappe halten
Keiner wird gezwungen, C zu benutzen. Ich kann daher nicht verstehen,
wie man derart darauf schimpfen kann. Ich schimpfe auch nicht auf
bestimmte Flugzeugtypen, nur weil ich sie nicht fliegen kann.
Übrigens:
Wenn hier einige Beiträge bei Dir arrogant ankommen, ist das Dein
Problem und nicht derjenigen, die sie geschrieben haben. Ich kann zum
Beispiel da überhaupt nichts arrogantes erkennen.
Das oben zitierte Statement von Dir war - nebenbei bemerkt - das einzig
sachliche von den vielen Beiträgen, die Du hintereinander abgefeuert
hast. Und witzigerweise spricht genau das für C - auch wenn das nicht
Deine Intention war. ;-)
A. K. schrieb:> Die K&R Version der Sprache hatte klare Mängel und auch offene Punkte,> war aber offensichtlich brauchbar.
Ja, sie war absolut brauchbar und für die damalige Zeit auf
UNIX-Systemen das Non-Plus-Ultra. Ich bin seit 1984 dabei - damals auf
Unix SVR4 und BSD Unix. Es gab damals einfach nichts vergleichbares,
welches soviel Entwicklungspotential hatte.
> Komplette> Unix-Systeme sind damit entstanden. Mitsamt X11 und Anwendungen.
Netzwerkfähige graphische Oberflächen - davon haben andere Konzerne wie
Microsoft damals noch ganz lange nur geträumt. Das X11-System ist -
trotz einiger Schwächen - auch heute noch einzigartig, was verteilte
Anwendungen betrifft. Der Window-Manager lief auf Unix-Maschine A, die
verschiedenen Anwendungen auf Maschine B und C - und das alles auf einem
Desktop.
Zeno schrieb:> Wenn es einen vernünftigen Pascalcompiler für µC geben würde,> dann würde ich keine Sekunde mehr mit C verschwenden.
Schreib einfach selber einen Pascalcompiler.
> Im übrigen hat sich Pascal auch weiter entwickelt und es kann nicht mehr> mit dem Pascal der 80'ziger und 90'ziger verglichen werden.
Merkwürdigerweise gibt es aber heute noch immer kein Betriebssystem, das
in Pascal geschrieben wurde. Warum wohl? Wenn Du mit Deinem
Pascalcompiler fertig bist, kannst Du damit ja anfangen.
P.S.
Ich würde mich an Deiner Stelle mal mit den Nachfolgesprachen von Pascal
beschäftigen. Ab Modula-2 sind die ganz brauchbar. Oberon zum Beispiel
hat durchaus das Zeug, damit auch ganze Betriebssysteme zu schreiben.
Gibt es sogar: Das ETH Oberon System ist ein eigenständiges
Betriebssystem der ETH Zürich, das in der Sprache Oberon implementiert
ist. Dagegen wirkt Pascal als ferner Vorfahre wie ein
Neandertaler-Dialekt.
Frank M. schrieb:> Merkwürdigerweise gibt es aber heute noch immer kein Betriebssystem, das> in Pascal geschrieben wurde. Warum wohl?
Sprachen sind meist nicht universell geeignet. Pascal eignet sich
weniger für Betriebssysteme, weil man darin so manche Schweinerei
braucht. Andererseits müssen Sprachen für Anwendungssysteme eine
Verwendung solcher Schweinereien nicht unbedingt nahe legen.
> Wenn Du mit Deinem> Pascalcompiler fertig bist, kannst Du damit ja anfangen.
Es gab ein Pascal Frontend im Rahmen von GCC. Ist aber eingeschlafen.
> Ich würde mich an Deiner Stelle mal mit den Nachfolgesprachen von Pascal> beschäftigen.
Yep. Wenn schon, dann da.
http://www.designtools.co.nz/mod51.htm
Mark B. schrieb:> Zeno schrieb:>> Noch so ein arroganter Rüpel.>> Der Yalu? Nicht Dein Ernst.>> Wenn Du hier regelmäßig liest, dann wirst Du feststellen dass seine und> Karl-Heinz Bucheggers Beiträge mit zum Besten gehören, was Du hier auf> mikrocontroller.net vorfinden kannst.
Wenn dem so ist, wie Du schreibst, dann hätte er sich den Vergleich mit
den Stützrädern mal sparen sollen.
Dieser Satz zeugt nach meinem Verständnis schon von einer gewissen
Arroganz. Nur weil er mit C programmiert erhebt es ihn nicht über Andere
die eine von C verschiedene Programmiersprache zur Lösung Ihrer Probleme
benützen.
Ich kenne schon einige Programmierer die sehr gute Software, u.a. auch
für den medizinischen Bereich, mit Delphi also Objektpascal schreiben,
und diese sind ganz bestimmt nicht mit Stützrädern unterwegs. Ich könnte
noch einige Beispiele nennen.
Jeder Programmierer soll die Programmiersprache benutzen, von der er
meint das er damit die gestellte Aufgabe am besten lösen kann. Ob diese
Sprache dann C, Pascal, Basic, Small Talk etc. etc. heißt, ist völlig
wurscht. Wichtig ist, das man auch mal über den Tellerrand hinaus schaut
und Arbeit / Leistung eines Anderen achtet.
Frank M. schrieb:> Nicht jeder ist für C geschaffen. Ohne Brain 1.0 wird das einfach nix. C> ist keine Programmiersprache für Leute, die ab und zu mal ein> Progrämmchen schreiben. Auch nach vielen Jahren lernt man als> C-Programmierer noch dazu. Wenn man sich intensiv mit C beschäftigt,> dann wird man irgendwann auch belohnt. Ist halt harte Arbeit und nix für> Prinzessinnen auf der Erbse. Für diese gibt es andere> Programmiersprachen (Pascal, Basic etc.), mit denen sie aber auch dort> nicht so weit kommen werden, wie sie eigentlich wollten, sondern ab> einer bestimmten Entwicklungsstufe einfach steckenbleiben.
Du bist einfach nur überheblich. Wahrscheinlich kennst Du noch nicht
einmal Pascal - zumindest keine aktuelle Version.
Wie gut es mit C bzw. dessen moderneren Abkömmlingen vorangeht, beweist
mir gerade ein junger Kollege, der mein für Firma in Delphi
geschriebenes Programm (welches im übrigen weltweit eingesetzt wird und
PTB-Zertifizierung erfolgreicht überstanden hat) versucht neu zu
implementieren. Er schreibt seit anderthalb Jahren daran und gerade mal
ca. ein sechstel der Funktionalität implementiert, die das Programm ganz
am Anfang nach ca. 10 Wochen Programmierzeit hatte. Vom aktuellen
Funktionsumfang reden wir mal gar nicht. Ach ja und nicht zu vergessen
bei dieser minimalen Funktionalität stürzt das Programm laufend ab. Ach
ja der Kollege hat Programmieren sogar richtig gelernt.
Also spare Dir Deine unsachlichen Kommentare.
Frank M. schrieb:> Von daher betrachte ich solche Schimpftiraden auf C lediglich ...
Und auch dies zeigt wieder mal, das es einige C-Programmierer gibt, die
sich sofort angepisst fühlen, sobald man Kritik an ihrem Lieblingskind
übt.
C hat nun mal Schwächen und die kann man nicht schön reden.
Aber Programmierer die etwas anderes als C benützen zu unterstellen sie
seien mit Stützrädern unterwegs oder im Sinn ähnliche Titulierungen
zeugen von Arroganz bzw. Überheblichkeit. Du bist halt auch so ein
Bursche - Du hast es in Deinem Post ja umfänglich bewiesen - und deshalb
kannst Du auch keine Arroganz erkennen.
A. K. schrieb:> weil man darin so manche Schweinerei ...
Du hast es erkannt.
Frank M. schrieb:> Dagegen wirkt Pascal als ferner Vorfahre wie ein> Neandertaler-Dialekt.
Jetzt bin ich aber froh das Du über das Neandertalerstadium hinaus
gekommen bist.
Frank M. schrieb:
(...)
>> Merkwürdigerweise gibt es aber heute noch immer kein Betriebssystem, das> in Pascal geschrieben wurde. Warum wohl? Wenn Du mit Deinem> Pascalcompiler fertig bist, kannst Du damit ja anfangen.>
gabsdoch:
https://de.wikipedia.org/wiki/Apollo/Domain
Thread beobachten
Seitenaufteilung abschalten