FORTH 1: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs

Welche Programmiersprache ist denn memory-safe? (ADA mit der kompletten Verbotsliste für "sichere" Programme zählt jetzt mal nicht)

Was bedeutet überhaupt memory-safe?

Bitte auch an Listen, Objekte, Out-of-Memory und an Rekursion denken?

Naja, ich habe ja geschrieben "im Großen und Ganzen". Und das stimmt auch -- die Mehrzahl unserer Geräte läuft auf Linux heutzutage, die ganzen Android Smartphones, quasi das ganze Rückgrat des Internet auch (sowohl Server als auch Router). HPC ist quasi ausschließlich Linux und damit C.

In C kann man Fehler machen, die schlimmere Auswirkungen haben als in anderen Programmiersprachen, das stimmt sicherlich. Aber jetzt zwei Fragen:

Erstens: Habe ich je behauptet, dass C *einfach* zu programmieren ist?

Zweitens: Ist es die Schuld des Werkzeugs oder des Bedieners, dass da Bugs in der Software sind?

Klar. Und trotzdem wird C nach wie vor sehr häufig verwendet. Jetzt kann man sich mit der Arroganz eines DoDi hinstellen und sagen: "Das ist nur weil alle blöd sind" oder man hält mal nicht alle anderen für Idioten und kommt auf ein Paar Aspekte, die andere Programmiersprachen halt nicht (in dem Umfang) leisten.

Google macht Chrome. Bei Google arbeiten mit Sicherheit viele der brilliantesten Software-Designer. Und *trotzdem* haben die sich für C als Implementierungssprache entschieden. Warum? Sind die Google-Ingenieure denn alle total blöd?

Oder, was ich für wahrscheinlicher halte: Es gibt knallharte Gründe, warum die diese Abwägung getroffen haben. Performance wird da eben auch ganz oben mit dabei sein. Weil wenn der Chrome plötzlich 20% oder 50% langsamer als der Firefox ist, dann sind die Benutzer weg. Gerade Browser sind *knüppelhart* optimierte Softwaremonster und da spielt Performance eine sehr große Rolle.

Das ist genau das undifferenzierte Argument, das mich an der ganzen Diskussion hier so ärgert: Wer C einsetzt ist einfach nur betriebsblind. Komplett die Vorteile wegignorieren und einfach nur das, was *du* für wichtiger hälst, hochpriorisieren. Das ist eines Ingenieurs absolut unwürdig.

Man stelle sich vor, ich würde mich in d.s.e hinstellen und sagen: "Schaut her, das hier ist der BESTE Transistor". Zu Recht würden mir da alle den Vogel zeigen und mich auslachen. Denn, wie bei jedem Werkzeug, gibt es viele Dimensionen: Verfügbarkeit, Preis, Geschwindigkeit, Second Source, das *alles* spielt eine Rolle.

Nur wenn es dann um Software-Werkzeuge geht, stellen sich Wolfgang, DoDi und ihresgleichen hin und posaunen Arrogant herum dass derjenige der "Transisor X" verwendet ja einfach nur n bissl doof ist und betriebsblind und weiß der Geier. Obwohl es da genau dieselben Dimensionen gibt: Geschwindigkeit, Verfügbarkeit, Language-Bindings, Portabilität, Speichersicherheit, etc etc.

Ich habe *nie* geschrieben, dass C die "beste" Sprache wäre. Nie, dass sie einfach oder idiotensicher zu programmieren ist. Sondern lediglich, dass es, nach Assembler, vermutlich die performanteste Sprache ist. Und solche Fakten schlicht zu ignorieren ist intellektuell unehrlich.

Gruß, Johannes

Ich vermute mal, und das ist jetzt ausrücklich meine Mutmaßung -- das das auf den Usecase ankommt. Insbesondere glaube ich, dass bei einem Benchmark, bei dem einem Pointergefriemel hilft, Pascal deutlich langsamer abschneiden würde als C. Vielleicht messe ich ja wirklich mal. Würde mich ehrlich interessieren und von Leuten wie DoDi kriegt man ja keine objektiven Zahlen sondern nur "ich hab das gemessen aber sag dir mein Ergebnis nicht ätschbätsch"

Ja! Danke!

JEDE Programmiersprache hat Nachteile, JEDE hat Vorteile. Genau das ist das, wie ein Ingenieur denkt. Ich muss einen Kompromiss finden, es gibt X verschiedene Dimensionen und halt üblicherweise keine global Optimale. Sondern jeweils nur in bestimmten Dimensionen optimal, und die muss eben jeder für sich (und für den jeweiligen Anwendungsfall) optimieren.

Genau, das ist beides vollommen richtig. Und vollkommen legitim.

Kann ich nur 100%ig unterschreiben. Die allermeisten Programmiersprachen haben ihre Daseinsberechtigung. Und die allermeisten Programmiersprachen sind nicht deswegen erfunden worden, weil den Erfindern langweilig war, sondern weil sie halt Wert auf einen Aspekt X gelegt haben, die Programmiersprache Y nicht so hatte.

Man muss aber halt ehrlich in seinen Vergleichen sein und nicht Cherrypicking mit bestimmten Aspekten betreiben.

Viele Grüße, Johannes

Am 21.08.2019 um 22:12 schrieb Johannes Bauer:

Quatsch, in Delphi kannst du auch *jede* Schweinerei kodieren, nur es geht da auch so, dass Delphi im Gegensatz zu einigen C-Programmen nicht als "Write-Only-Language" daherkommt.

Meine Lieblings-URL dazu ist

Ich habe 25 Jahre Delphi hinter mir, und es gab kein Problem, was nicht zu lösen war, auch hardwarenahe Anwendungen, die heftige Datenraten abliefern mussten.

Schneller Anwendungen gehen m.E nur noch durch CUDA, aber das ist mir als Alter Sack zu hoch (seit einem Jahr im Ruhestand).

Gruß, Alfred.

Am 21.08.19 um 21:02 schrieb Gerhard Hoffmann:

Paßt nicht so recht, daß Hans-Peter ja gerade kein C verwenden möchte.

Die $400 Billion durch Hacker im Jahre 2015 auch? Ich hab Quellen angegeben. Die mögen nicht gut sein, aber besser als quellenfreie Zweifel sind sie allemal.

Keine Ahnung, welches Windows du meinst, aber wenn man im Jahre 2015 von den letzten 12 Jahren spricht, dann geht es wohl nicht weiter zurück als Windows XP, und das wurde in C, C++ und Assembler geschrieben. Mal ganz abgesehen davon, daß es nicht nur um Windows geht und ich Pascal nicht mal erwähnt habe.

Hanno

Am 21.08.2019 um 21:02 schrieb Gerhard Hoffmann:

In den 90er Jahren enthielt jedes Modul im WinSDK ca. 50 haarsträubende Fehler, die der Compiler eines ordentlichen C++ Entwicklungssystems angemeckert hat. Oh f*ck - dieser Compiler stammte von den Delphi-Entwicklern! So viel zum Vorteil eines Umstiegs auf C :-]

DoDi

Am 21.08.2019 um 22:05 schrieb Johannes Bauer:

Das ist eine unbewiesene/unbeweisbare Behauptung. Richtig ist lediglich, daß C die meist*verwendete*[1] Sprache ist.

Nicht mal die Performance kannst Du richtig einschätzen, die ist bei den heutigen (Intel-)Prozessoren mit einer Hochsprache oft besser als mit Assembler.

Fakten, alternative?

DoDi

Am 21.08.2019 um 20:58 schrieb Johannes Bauer:

DoDi

Am 21.08.2019 um 21:29 schrieb Stefan Engler:

Huh? Sowas ist mir zumindest in Delphi noch nie begegnet.

Kannst Du das belegen?

DoDi

Am 21.08.2019 um 22:12 schrieb Johannes Bauer:

Man kann jeden Benchmark fälschen. Wer damit was anderes als Compiler der gleichen Programmiersprache vegleicht, hat spezielle Eigeninteressen.

Bei meinem Nachbau des ACK war Delphi ca. 5% langsamer als C.

Natürlich bedankt sich da einer gleich für solche fake news, wenn er keine Ahnung von Pascal hat :-]

So wie das Herumreiten auf Benchmarks mit unglaublichem Faktor 500?

DoDi

Dann ist es ja genauso unsicher wie C. Und wieder ist Cherrypicking am Start: In einem Thread wird behauptet, Pascal sei C überlegen, weil es genau diese Fähigkeit nicht hat. Du sagst jetzt, ja nee, ich kann das genauso schlecht wie C, unsicheren Speicherzugriff.

Nur weil es sich schrecklich anhört, wenn ich Geige spiele, heißt das nicht, dass die Geige ein untaugliches Musikinstrument ist.

Naja, "Hass" ist schonmal ein ganz schlechtes Argument, sondern eher was für Dogmatiker. Leute also, die lieber Glauben als zu wissen.

Inhaltlich extrem viel amateurhafte Anfängerfehler, die in der Praxis keine Rolle spielen. Und für die, nebenbei gemerkt, jeder vernünftige Compiler dutzendweise Warnungen generiert.

Ja du, ich programmiere jetzt seit etwa 20 Jahren C, ich glaube ich kenne die Sprache ganz gut. Ihre Stärken und Schwächen. Aber danke, trotz herablassendem Ton.

Mit Delphi kriegst du halt aber z.B. keinen Kerneltreiber implementiert. Ist jetzt nur ein Beispiel, aber das habe ich schon gemacht.

Delphi habe ich früher auch mal programmiert, insbesondere das GUI RAD hat mir wirklich gut gefallen. Sowas gut gelöstes suche ich immernoch vergeblich (obwohl GTK/Glade da mittlerweile fast, aber nur fast, rankommt).

Kommt immer drauf an, was man macht, was sich massiv parallelisieren lässt läuft natürlich auf einer GPU schneller. Auch sowohl CUDA als auch OpenCL orientieren sich syntaktisch übrigens an C++/C, nur ganz nebenbei.

Viele Grüße, Johannes

Ach komm, bist du wirklich ein Lügner vom Kaliber des Allinger? Versuchst du tatsächlich das OFFENSICHTLICHE zu leugnen? Was für eine moralische Bankrotterklärung.

Aber, hey, ich spoonfeede dich jetzt mal und dann schauen wir mal ob du zugeben kannst, was für Müll du hier zusammengelogen hast:

Handgeschriebens Assembler ist schon deswegen IMMER mindestens genauso gut wie jede Hochsprache, weil ich einfach einen Compiler nehmen kann, das zu Assembler runterkompilieren und dann meinen mindestens gleichguten Assembler-Code habe.

Dass du solch simple Fakten nicht verstehst, zeigt eindrucksvoll deine komplette und unfassbare Ahnungslosigkeit. Noch gepaart mit einer Überheblichkeit, die ihresgleichen sucht.

Mensch, wenn die nur mal alle auf dich hören würden, oh erleuchteter DoDi.

Gruß, Johannes

Am 21.08.19 um 22:05 schrieb Johannes Bauer:

Ja, sicherlich. Es tut irgendwelche Dinge. Ob gut, billig, effektiv, nebenwirkungsfrei etc. ist völlig egal, wenn man wegen der installierten Basis, in die sich Änderungen und Erweiterungen einpassen müssen, kaum Alternativen hat und infolgedessen die Programmierer auch keine kennen: If you only have a hammer, everything looks like a nail. Aber "gut genug", um aus dem lokalen Minimum nicht rauszumüssen, ist es wohl.

Natürlich ist es die Schuld des Werkzeugs, wenn es Fehler ermöglicht, die mit einem anderen Werkzeug erst gar nicht vorkommen können. Was ist das denn für eine Frage?

Windows wird auch sehr häufig verwendet. Liegt das an der überragenden Qualität von Windows, oder an der installierten Basis, und daran, daß die Leute nichts anderes kennen?

Und trotzdem konnten sie nicht gut genug programmieren, um die 70% high-risk bugs zu vermeiden, die ihnen C als Fußangel ermöglicht hat. Bist du sicher, daß das ein Argument für C ist? Rat mal, wie das bei schlechteren Programmierern aussieht.

Natürlich: Angesichts der Popularität von C bekommst du für ein Großprojekt kaum genügend Programmierer für eine andere Programmiersprache zusammen.

Und natürlich, daß Bugs nichts kosten (Unter anderem, weil sich die Leute an sie gewöhnt haben. Alles ist kaputt. Isnumalso. Netter Talk zum Thema:

Wenn du hier komplett die Nachteile wegignorierst, bis zu dem Zeitpunkt, wo ich sie dir an die Stirn tackere, ist das schon irgendwo betriebsblind. Ich hingegen brauche nicht zu erwähnen, daß Dinge, die in großem Maße eingesetzt werden, sicher irgendwo auch Vorteile haben: Das ist selbstverständlich.

Nur hab ich nichts als bestes bezeichnet. Und auch nicht C als schlechtestes. Deine Einstellung ist mir lediglich gegenüber C zu undifferenziert kritiklos.

Hanno

Ohje, DoDi, kommen dir jetzt auch die Tränchen, weil Zahlen meine Argumente untermauern und deine widerlegen?

Ja voll die gemeine Fälschung, muss so sein. Dass jemand mit simpelsten Mitteln deine Lügen als solche entlarvt, das kann echt nicht sein. Total fies, ey!

Schreib doch mal genau, was da "gefälscht" sein soll. Du kannst übrigens auch alles nachvollziehen, komplett transparent und mit vollem Sourcecode. Also, wenn du dazu in der Lage bist, deinesgleichen der Wolfgang war dazu ja nicht kompetent genug und du scheinst mir da nicht weit von entfernt zu sein.

Klar, poste doch mal den Sourcecode. Dann vergleiche ich das selber. Du kannst ja meinen Code auch sehen und vergleichen.

Oder -- warte! -- sind das GEFÜHLTE Messwerte? Die du noch so ungefähr im Kopf hast?

Ich habe das, wenn du mich nicht absichtlich falsch zitieren würdest, darauf bezogen, dass jede Programmiersprache Nachteile hat. Sollte auch aus dem Kontext selbst dem Dümmsten -- also dir -- klar werden.

Messung, Junge, Messung. Mach doch mal selber eine bevor du hier dummes Geschäwtz ablässt.

Viele Grüße, Johannes

Am 21.08.2019 um 23:55 schrieb Johannes Bauer: [...] <gähn>

DoDi

Am 21.08.19 um 23:55 schrieb Johannes Bauer:

Hä? Das ist wirr. Die Frage ist, ob du von Hand genausogut optimieren kannst wie ein Compiler. Und das wurde schon vor 2 Jahrzehnten von qualifizierter Seite bezweifelt - spätestens, wenn der Code umfangreicher wird.

Hanno

Am 21.08.2019 um 23:41 schrieb Johannes Bauer:

Ich bezog mich nur auf das hochgelobte "Pointergepfriemel". Der Kompiler ist schon richtig schlau, dass er vor unsicherem Code warnt. Nur beachten muss man das ja nicht.

Mozart ist besser als Katzenjammer ;-)

Das musst du mir erklären, ich sag mal ins Blaue, das stimmt nicht.

:-)

Der Wermutstropfen: Delphi kostet richtig viele Ocken, C-GUIs gibt es meist für Umme.

Da hast du leider recht.

Gruß, Alfred.

Wenn ich Assembler schreibe, kann ich mich immer *jedes* Compilers bedienen. Also konkret: Ich habe die Möglichkeit, mein Programm durch zig verschiedene Compiler zu assemblieren und *zusätzlich* die Möglichkeit, das zu verändern oder ganz neu zu schreiben. Deswegen ist es notwendigerweise immer mindestens gleichschnell.

Ob man das "blind" hinkriegen könnte, ist eine ganz andere Frage. Und dass es viel mehr Wissen braucht, noch zusätzlich was ganz anderes. Üblicherweise wird "umfangreicher" Code aber auch nicht mehr in Assembler geschrieben, sondern eben nur die kritischen Pfade. Die, wo es eben einen Unterschied macht, ob Hochsprache oder nicht.

Fakt ist, dass performance-kritischer Code sich heute immernoch an Assembler bedient. Sieht man z.B. dutzendfach in OpenSSL. Oder bei djb's Kryptocode. Oder bei BLAS.

Gruß, Johannes

Am 22.08.2019 um 00:00 schrieb Johannes Bauer: [...]

dann mach doch selber einen Benchmark, damit ich Deinen Quelltext

ordentlichen (vergleichbaren) FORTH oder Pascal Code. Dein

beweisen zu wollen.

Entwicklungsumgebung ist. Wenn Du das auf Benchmarks reduzierst, dann kannst Du mir nur noch leid tun :-(

WinHelp Decompiler. Danach habe ich nur noch in Delphi codiert, weil das einfacher, sicherer und schneller ging als in C oder C++. Sowohl was die Entwicklung als auch die Laufzeit betrifft.

DoDi