Skriptsprachen-Hassen leicht gemacht

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Mittwoch 24. Januar 2007, 17:30

sape hat geschrieben:Dan fehlt dir der Humor. Ich kann sehr gut über solche derben Sachen und Idioten lachen ;) Und das witzige ist, das er das nicht mal als Humor dargestellt habe will (denke ich mir mal so.), sonder so als ob das sein voller Ernst ist :lol: Und gerade diese unsachlich, zynische Art die er im Artikel nutzt, vermischt mit Fakten, ist sehr amüsant.

Nein, mir geht es nicht darum, dass es zynisch und als voller Ernst dargestellt ist, sondern darum, dass die Satire nicht einmal subtil durschscheint. Das sollte bei einer Satire aber sein, sonst liest es sich eben so.. unlustig eben. Besser gemacht finde ich das bei Shelley The Republican.

sape hat geschrieben:Also, gib den beiden artikeln eine Chance. Wenn du dich halbwegs mit dem auskennst was er da bespricht, wirst du deinen Spaß an seinen überflüssigen Kommentaren haben :D

Nö - schon die von Y0Gi hingewiesene Sache mit den static typing ist völlig verbockt. Und ich kenne mich mit dem Thema durchaus ein wenig aus. Ebenso ist das anmängeln der Syntax total daneben, das ist nicht lustig das ist blöd. Man kann durchaus eine angenehme Sprache mit Curly Braces machen. Schaut euch mal blackbird an, der findet seit letztens auch JavaScript toll.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
BlackJack

Beitragvon BlackJack » Mittwoch 24. Januar 2007, 18:15

Leonidas hat geschrieben:Ebenso ist das anmängeln der Syntax total daneben, das ist nicht lustig das ist blöd. Man kann durchaus eine angenehme Sprache mit Curly Braces machen.


Ich glaube nicht, dass es um die Curly Braces an sich geht ─ die Kritik zur Syntax greift auch, wenn man die durch Schlüsselworte wie BEGIN und END ersetzt. Man nimmt bei C und ähnlichen Sprachen viel als gegeben hin, was bei näherer Betrachtung ziemlich eigenartig ist und teilweise Fehler begünstigt die einfacher vermieden werden könnten, wenn gewisse Sachen nicht erlaubt wären. Zum Beispiel hätte man bei ``if``, ``while``, ``for`` usw. Blöcke statt Statements in der Syntax vorsehen können. Da wäre niemand dran gestorben. Also in den Anfangszeiten als es noch Rechner/Tastaturen ohne geschweifte Klammern gab vielleicht schon, aber spätestens bei Java oder C# hätte man die Statements an der Stelle abschaffen können.
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Beitragvon sape » Mittwoch 24. Januar 2007, 18:39

Leonidas hat geschrieben:Ebenso ist das anmängeln der Syntax total daneben, das ist nicht lustig das ist blöd. Man kann durchaus eine angenehme Sprache mit Curly Braces machen. Schaut euch mal blackbird an, der findet seit letztens auch JavaScript toll.
Es geht doch nicht um ``{}``-Syntax im Zusammenhang mit Inkonsistenz. Darum ging es auch nicht dem Autor das ``{}`` benutzt wird. Nein, es geht darum, wie Jack schon sagt, um wirklich strange inkonsistente Sachen.

Hier mal ein Beispiel:

Code: Alles auswählen

int a=1, b=2;
if (a=b) {
  printf("a ist gleich b\n");
};

Wenn man das Programm startet, erscheint die Ausgabe "a ist gleich b", obwohl a und b ganz offensichtlich verschieden sind. Der versierte C-Nutzer sieht bei diesem einfachen Beispiel natürlich sofort den Fehler - gemeint war wohl (a==b) - nur warum merkt der Übersetzer das nicht?
Ja, weil erstens a=b zwar hauptsächlich eine Anweisung ist, welche den Wert von b in a hineinkopiert, zusätzlich ist aber a=b auch noch ein Ausdruck, welcher b als Wert zurückliefert . Für die if-Anweisung hätte es also den gleichen Effekt, als würde man gleich if(b) schreiben. Und das wird zweitens dummerweise auch noch akzeptiert, weil if nicht zwischen Wahrheitswerten und Ganzzahlen unterscheidet.

Das ist ja noch harmlos.

Code: Alles auswählen

int a=10, b=8, c=6;
if (a<=b<=c) {
   printf("%d <= %d <= %d\n", a, b, c);
}

Man staunt und wundert sich, ob der Rechner jetzt wohl die Relationszeichen vertauscht hat, weil dieses Programm tatsächlich behauptet, dass 10 ≤ 8 ≤ 6. Der Grund ist einmal mehr im versuppten Typenkonzept von C zu finden. Der Übersetzer geht so vor: Der Ausdruck wird von links nach rechts ausgewertet, das entspricht der Klammerung ((10≤8)≤6). Jetzt wird der erste Vergleich ausgewertet: 10≤8 ist falsch, für C entspricht das einer 0. Nun wird diese 0 in den zweiten Vergleich gesteckt: 0≤6 ist wahr, also für C gleich 1, also für if wiederum wahr. Dumm gelaufen, was?
Dass wir uns nicht falsch verstehen: Der Übersetzer braucht diese verketteten Vergleiche nicht zu unterstützen. Sie sind Schreibvereinfachungen, die sich aber nicht damit vertragen, dass Vergleiche eigentlich Relationen zwischen zwei und zwar genau zwei Werten sind. Aber man kann von dem Übersetzer erwarten, dass er solche Irrtümer bemerkt, weil es eigentlich keine sinnvolle Interpretation für den Ausdruck "10 ≤ 8 ≤ 6" gibt, wenn man "≤" als Operation mit zwei Argumenten (linke Seite und rechte Seite) auffasst. Diese Sichtweise ist auch sinnvoll, denn alles andere wäre kaum wasserdicht zu definieren.
Hey, aber auch das ist ja noch nicht sooo schlimm.


Preisfrage: Was steht hier?

pi * diameter;

Blöde Frage, das ist natürlich die bekannte Formel zur Berechnung des Kreisumfanges aus dem Kreisdurchmesser. Lediglich das Speichern des Ergebnisses wurde vergessen.
Schaut noch einmal genau hin. Ganz genau. Würdet ihr eure Antwort ändern, wenn ich noch 100 Euro drauf lege? Ach nein, das ist die falsche Sendung.
Ich habe noch nicht verraten, dass pi ein Typbezeichner ist. Er steht für "product information" oder so und wird weiter oben im Programm definiert. Demnach wird hier die Zeigervariable diameter eingeführt, welche auf Objekte vom Typ pi zeigt.
Wir sehen, dass in C die Syntax für Deklarationen und arithmetische Ausdrücke nicht unterschieden werden kann, dass man also zum Erkennen der Programmstruktur bereits Informationen über die Bedeutung der Bezeichner benötigt. Bei C++ wird übrigens alles noch viel besser.


Nachdem wir nun schon so viel Spaß mit dem Anlegen von Feldern hatten, wie ist es dann mit der Benutzung derselben? Wenn a ein Feld ist, dann bezeichnet a[i] dessen i. Eintrag. Lustigerweise bezeichnet i[a] aber dasselbe! Der Grund ist, dass a[i] syntaktischer Zucker für *(a+i), wobei a+i Zeigerarithmetik ist. Bei der Addition eines Zeigers a und einer ganzen Zahl i (Reihenfolge egal) hat das Ergebnis den Typ des Zeigers. Allerdings wird nicht einfach der Wert von i zu dem Zahlenwert des Zeigers a addiert, sondern es wird das Produkt von i und der Größe des Datums, auf das a zeigt, zu a addiert. Diese Erkenntnisse sind essentiell, um bei Wettbewerben um möglichst unverständlichen C-Code gut abschneiden zu können.
Da muss noch mehr herauszuholen sein! Wie wär's denn mit zweidimensionalen Feldern? Normalerweise indiziert man ein zweidimensionales Feld a so: a[i][j]. Aber mit unserem Wissen können wir das gleiche viel schöner schreiben, etwa:

* i[a][j]
* j[i[a]]
* j[a[i]]
* (a+i)[0][j]
* ((a+i)[0]+j)[0]
* j[*(a+i)]
* (*(a+i))[j]
* *((a+i)[0]+j)

Das ist ein absolut unverzichtbares Werkzeug um den Lesern seiner Programme überdurchschnittliches Wissen über C zu demonstrieren. Entwickler aller Länder schätzen es, Programme von solch erfahrenen Programmierern weiterentwickeln zu dürfen.
Das ist einer meiner Lieblinge ;)

*i*
Hey, ist aber alles nicht so schlimm. Man lernt es auswendig und macht dann diese Fehler die daraus resultieren könne nicht mehr. Auch Bufferoverflow oder Speicherlecks lassen sich als Profi vermeiden...
*/i*

BTW: Und das ist ja noch nicht 10% der Inkonsistenz die in C existiert. Was ich besonders schön an C finde ist die richtig starke Typsicherheit! ;)

Nett ist auch folgendes: http://www.wackerart.de/c.html
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Mittwoch 24. Januar 2007, 21:00

sape hat geschrieben:*i*
Hey, ist aber alles nicht so schlimm. Man lernt es auswendig und macht dann diese Fehler die daraus resultieren könne nicht mehr. Auch Bufferoverflow oder Speicherlecks lassen sich als Profi vermeiden...
*/i*

Nicht dass es keine GCs für C gäbe, oder Tools wie Valgrind. Und gegen Inkompetenz ist sowieso kein Kraut gewachsen. Denn auch in Python kann man tolle Sachen machen wie exec & Co, XSS-Lücken in Webseiten, CrossSite Forgery etc. etc. Um das zu vermeiden, muss man ja nichteinmal Profi sein. Und Speicherlecks in C lassen sich auch als Nichtprofi vermeiden.

Zu der Inkonstistenz: er bemängelt etliche Sprachen die geschweifte Klammern haben, aber nicht unbedingt die gleiche Inkonsistenz wie C. Das ist doch ebenso grundlos.
My god, it's full of CARs! | Leonidasvoice vs Modvoice

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder