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

[Gerhard Hoffmann]

Am 21.08.19 um 20:16 schrieb Hanno Foest:

Am 21.08.19 um 19:17 schrieb Johannes Bauer:

C ist zweifelsohne "brauchbar". Sonst würde nicht der Großteil aller
Software auf C-Software basieren.

Wenn es brauchbar wäre, dann wären die damit erzeugten Programme nicht
so fehlerbehaftet.

It's a bad craftsman who blames his tools.

Dass es "brauchbar" ist, zeigt, dass der Großteil unserer heutigen
IT-Infrastruktur darauf basiert. Und im Großen und Ganzen prima
funktioniert.

FĂźr bestimmte Werte von "prima". Es gibt zigtausende CVEs, und alleine
in Deutschland betrugen 2006 die jährlichen Verluste durch
Softwarefehler in Mittelstands- und Großunternehmen 84,4 Mrd. Euro.

Bei 3000 Mrd BSP in 2006 erscheinen 84,4 Mrd Verluste in Mittel- und
Großunternehmen nur durch Softwarefehler doch reichlich aus dem Vollen
geschĂśpft. Da bin ich noch nicht mal dabei. Und keine Virusattacken.
Und die Maurer, Bierbrauer und Bauern auch eher nicht. Die haben ja
auch einen Anteil am BSP.
Das ganz und gar UNGLAUBLICHE FIASKO von pleitegegangen Firmen im
Kielwasser der Jahrtausendwende war 2006 ja wohl verdaut.

Nun lassen sich aber 70% aller Sicherheitsprobleme in Software von
Microsoft auf unsicheren Umgang mit Arbeitsspeicher zurĂźckfĂźhren

https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/


und bei den Programmiersprachen mit unsicherem Umgang mit
Arbeitsspeicher ist C nun mal ganz weit vorne.

Das ist aber ein klassisches Eigentor, Windows wurde in Pascal
geschrieben. Mit der Umstellung auf die C-Familie wurde das dann
deutlich besser. Windows 7 ist eigentlich schon ganz brauchbar.

Gerhard

 

[Johannes Bauer]

On 21.08.19 20:28, Hans-Peter Diettrich wrote:

Dass es "brauchbar" ist, zeigt, dass der Großteil unserer heutigen
IT-Infrastruktur darauf basiert. Und im Großen und Ganzen prima
funktioniert.

Jupp, insbesondere die LĂźcken fĂźr Viren etc.

Uargh, du kennst also nicht mal den Unterschied zwischen Viren und WĂźrmern.

Darum ging es gerade gar nicht. Ich nutze kein Pascal, habe das mal als
Kind gelernt und fand es ganz nett. Aber eine Programmiersprache, fĂźr
die es halt keine gescheiten Compiler gibt,

Die ersten C Compiler und Bibliotheken waren auch nicht besonders
"gescheit". Wenn die in ihrem K&R Stand verblieben wären, wßrde sich
heute auch niemand mehr mit C befassen.

Und wieso meinst du hat sich jemand die MĂźhe gemacht, fĂźr C die Compiler
zu verbessern? Einfach nur aus Jux & Dollerei? Reiner Zufall?

Performance ist nicht das Problem, es läuft ja nachher beides
auf der selben Hardware.

LOL, "Performance ist nicht das Problem" sagen immer genau die, die eben
NICHT dieselbe Performance hinkriegen. Das haben die Java-Leute schon
*jahrzehnte* herumposaunt.

Der Vergleich von Äpfeln mit Birnen, typisch für viele Apostel :-(

Was sind hier denn jetzt Äpfel und was Birnen? Es gibt *dutzende*
ähnliche Implementierungen von Software in sowohl C als auch in Java.
Vom Webserver bis zur RS232-Library ist da alles dabei. Und im
Gegenteil, die Java-BefĂźrworter vergleichen sich ja gern selbst in der
Performance mit C, das ist da ja nämlich der Goldstandard.

Mach doch mal Messungen. Gerne auch Pascal vs. C.

Das würde ich *Dir* einmal empfehlen, mir ist der kaum meßbare
Unterschied bekannt.

Soll ich mir echt die MĂźhe machen, damit du mit genauso
heruntergelassenen Hosen dastehst, wie Wolfgang? Wenn bei ner Pascal RC4
Implementierung dann Faktor 10 unterschied rauskommt, ist das noch "kaum
messbar"? Oder ab welchem Faktor wirst du Ăśffentlich proklamieren, dass
du kompletten Unsinn geschrieben hast?

Was ich vermute: Wenn ich solche Ergebnisse tatsächlich MESSE und dann
hier poste, dann wirst du nur wieder das Ziel ändern: "Ach ne der
COmpiler ist schlecht, das liegt Ăźberhaupt nicht an der Sprache
blablabla". Weil du nicht die Größe hast, deine falschen Behauptungen zu
revidieren.

Wer die Weiterentwicklung von C/C++ beobachtet,
der stellt fest, daß dort immer mehr Paradigmen einfließen, die in
Pascal schon seit Jahrzehnten Standard waren.

Äh, ne, ganz sicher nicht.

Nun ja, mit solchen Aposteln lohnt sich eine weitere Diskussion nicht.

Ich *kenne* C++. Du hast Null Ahnung und kannst nicht EINEN EINZIGEN
Beleg anfĂźhren fĂźr deine Behauptung. Statt eine zu liefern spielst du
die beleidigte Leberwurst und hoffst, dass niemand deine komplette
Ahnungslosigkeit bemerkt.

Aber sowas von Tausendprozentig nicht. Was
sind denn neue Paradigmen so in C++11, C++14, schauen wir doch mal:
auto, constexpr, lambda-Funktionen. Kann Pascal alle snicht. Template
Metaprogramming ja wohl sowas von auch nicht. LValue-Referenzen zur
Effizienten Kopie von Objekten, nĂśp. Ich vermute, du hast von
C++-Programmierung und dem, was in der C++-Welt mit C++20 so gerade
vorgeht,

Eben weil ich mitbekomme, was sich da abspielt :-]

Was bekommst du denn mit? Gib es doch zu: Du hast doch keinerlei Ahnung
von den Sprachfeatures, die ich da gerade aufgelistet habe, richtig? Und
musstest sie alle googeln, oder?

schlicht und ergreifend keine Ahnung. Ich schon.

Deine Beschränktheit auf C++ disqualifiziert Dich nur. Prählen kÜnntest
Du eher mit Kenntnis von C#, Ada oder OPL. Aber mit C Scheuklappen...

Na du bist ja witzig -- denn DU warst der, der C++ ins Spiel gebracht
hat. Du! Und dann stellt sich heraus, dass ich mich da ganz gut
auskenne. Peinlich fĂźr dich, so fliegt deine Unkenntnis halt auf ganzer
Linie auf. Wenn du wissen willst, was fĂźr Sprachen ich sonst noch so
programmiere, kannst du ja mal in mein Github Repo schauen.

Aber ich finde es echt immernoch erstaunlich dass du, als Informatiker
(schon, oder?) die himmelschreiende Arroganz hast, anderen Leuten
vorschreiben zu wollen was eine "bessere" Programmiersprache ist. Du
siehst ein Auto und sagst, die machen ganz viele Unfälle und das ist
schlimm. Autos sind megaschlecht. UNd dann stellst du mir ein Fahrrad
hin und sagst: "Hier das ist VIEL besser, dem Auto total Ăźberlegen, und
die Geschwindigkeit ist echt nicht so wichtig". Das ist aber halt eben
MEINE Entscheidung als Ingenieur, was in MEINER Applikation wichtig ist
und nicht die eines vollkommen Ahnungslosen, sich selbst ßberschätzenden
DoDi.

Gruß,
Johannes

 

[Alfred Gemsa]

Am 21.08.2019 um 22:12 schrieb Johannes Bauer:

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"

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

http://www.henning-thielemann.de/CHater.html

Lies das mal in Ruhe, und vielleicht auch einige weiterfĂźhrende Links.

Es wird immer Software in einer unĂźblichen Programmiersprache geben, wo
jemand ein gutes Auskommen findet.

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.

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.

 

[Johannes Bauer]

On 21.08.19 21:29, Stefan Engler wrote:

Am 21.08.2019 um 19:17 schrieb Johannes Bauer:
Von C Programmierern wird Pascal belächelt, ohne
daß sie die Vorteile von Pascal in der Programmentwicklung überhaupt
kennen.
Darum ging es gerade gar nicht. Ich nutze kein Pascal, habe das mal als
Kind gelernt und fand es ganz nett. Aber eine Programmiersprache, fĂźr
die es halt keine gescheiten Compiler gibt, keine gescheiten Language

Pascal lässt sich genauso verwenden wie C und es gibt auch einige
komerzielle Programme mit Pascal/Delphi. Wenn die schlecht Ăźbersetz-
baren Funktionen vermieden werden, ist Pascal fast so schnell wie C.

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"

Jede Programmiersprache hat Nachteile und bei Pascal gibt es aufgrund
des Aufbau des Compilers einige wenige Anweisungen, die z.B. als sich
selbst modifizierendes Programm Ăźbersetzt werden. Dies ist sehr
aufwendig und fĂźr Harvard-Architekturen sogar untauglich.

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.

In C gibt es ein unglaubliche Vielzahl an Bibliotheken, die sich einfach
nutzen lassen. Ganauso kĂśnnte ich aber auch argumentieren, dass Mono
oder .Net oder C++ mit den Vtables von Windows wesentlich besser umgehen
kann.

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

[...]

Es wird immer Software in einer unĂźblichen Programmiersprache geben, wo
jemand ein gutes Auskommen findet.

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

 

[Johannes Bauer]

On 21.08.19 20:16, Hanno Foest wrote:

Dass es "brauchbar" ist, zeigt, dass der Großteil unserer heutigen
IT-Infrastruktur darauf basiert. Und im Großen und Ganzen prima
funktioniert.

FĂźr bestimmte Werte von "prima".

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.

Es gibt zigtausende CVEs, und alleine
in Deutschland betrugen 2006 die jährlichen Verluste durch
Softwarefehler in Mittelstands- und Großunternehmen 84,4 Mrd. Euro.

https://de.wikipedia.org/wiki/Programmfehler#Wirtschaftliche_Bedeutung

Es ist seitdem sicher nicht weniger geworden.

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?

und bei den Programmiersprachen mit unsicherem Umgang mit
Arbeitsspeicher ist C nun mal ganz weit vorne.

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.

Das mit den 70% ist wohl nicht nur bei Microsoft so, stichprobenartig:
"70% of the high-risk bugs in Chrome 44 would have been prevented if
Chrome were written in a memory-safe language instead of C/C++."

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 mit dem "brauchbar" ist halt so ne Sache. Es tut Dinge, sicher.
Vielleicht sogar schnell. Und wenn man betriebsblind genug ist, sieht
man auch die Kollateralschäden nicht. Obgleich die immer häufiger
kommenden, immer größeren Sicherheitsupdates auch dem Betriebsblindesten
zeigen sollten, daß Sprachen mit bekannten Sicherheitsimplikationen mit
der immer weiter zunehmenden Komplexität der Software nicht so recht
harmonieren.

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

 

[Hans-Peter Diettrich]

Am 21.08.2019 um 21:02 schrieb Gerhard Hoffmann:

Am 21.08.19 um 20:16 schrieb Hanno Foest:
Am 21.08.19 um 19:17 schrieb Johannes Bauer:

und bei den Programmiersprachen mit unsicherem Umgang mit
Arbeitsspeicher ist C nun mal ganz weit vorne.

Das ist aber ein klassisches Eigentor, Windows wurde in Pascal
geschrieben. Mit der Umstellung auf die C-Familie wurde das dann
deutlich besser. Windows 7 ist eigentlich schon ganz brauchbar.

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

 

[Hans-Peter Diettrich]

Am 21.08.2019 um 20:58 schrieb Johannes Bauer:

[...]
<gähn>

Gruß,
Johannes

DoDi

 

[Hans-Peter Diettrich]

Am 21.08.2019 um 22:12 schrieb Johannes Bauer:

Pascal lässt sich genauso verwenden wie C und es gibt auch einige
komerzielle Programme mit Pascal/Delphi. Wenn die schlecht Ăźbersetz-
baren Funktionen vermieden werden, ist Pascal fast so schnell wie C.

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.

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

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"

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

Jede Programmiersprache hat Nachteile und bei Pascal gibt es aufgrund
des Aufbau des Compilers einige wenige Anweisungen, die z.B. als sich
selbst modifizierendes Programm Ăźbersetzt werden. Dies ist sehr
aufwendig und fĂźr Harvard-Architekturen sogar untauglich.

Ja! Danke!

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

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

So wie das Herumreiten auf Benchmarks mit unglaublichem Faktor 500?

DoDi

 

[Hans-Peter Diettrich]

Am 21.08.2019 um 21:29 schrieb Stefan Engler:

Jede Programmiersprache hat Nachteile und bei Pascal gibt es aufgrund
des Aufbau des Compilers einige wenige Anweisungen, die z.B. als sich
selbst modifizierendes Programm Ăźbersetzt werden.

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

Kannst Du das belegen?

DoDi

 

[Johannes Bauer]

On 21.08.19 22:33, Alfred Gemsa wrote:

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"

Quatsch, in Delphi kannst du auch *jede* Schweinerei kodieren,

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 es
geht da auch so, dass Delphi im Gegensatz zu einigen C-Programmen nicht
als "Write-Only-Language" daherkommt.

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

Meine Lieblings-URL dazu ist

http://www.henning-thielemann.de/CHater.html

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.

> Lies das mal in Ruhe, und vielleicht auch einige weiterfĂźhrende Links.

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.

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

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.

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).

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

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

 

[Hans-Peter Diettrich]

Am 21.08.2019 um 22:05 schrieb Johannes Bauer:

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.

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.

Und
solche Fakten schlicht zu ignorieren ist intellektuell unehrlich.

Fakten, alternative?

[1] Millionen Fliegen kĂśnnen bekanntlich nicht irren :-(

DoDi

 

[Hanno Foest]

Am 21.08.19 um 21:02 schrieb Gerhard Hoffmann:

Wenn es brauchbar wäre, dann wären die damit erzeugten Programme nicht
so fehlerbehaftet.

It's a bad craftsman who blames his tools.

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

Dass es "brauchbar" ist, zeigt, dass der Großteil unserer heutigen
IT-Infrastruktur darauf basiert. Und im Großen und Ganzen prima
funktioniert.

FĂźr bestimmte Werte von "prima". Es gibt zigtausende CVEs, und alleine
in Deutschland betrugen 2006 die jährlichen Verluste durch
Softwarefehler in Mittelstands- und Großunternehmen 84,4 Mrd. Euro.

Bei 3000 Mrd BSP in 2006 erscheinen 84,4 Mrd Verluste in Mittel- und
Großunternehmen nur durch Softwarefehler doch reichlich aus dem Vollen
geschĂśpft.

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.

Nun lassen sich aber 70% aller Sicherheitsprobleme in Software von
Microsoft auf unsicheren Umgang mit Arbeitsspeicher zurĂźckfĂźhren

https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/

und bei den Programmiersprachen mit unsicherem Umgang mit
Arbeitsspeicher ist C nun mal ganz weit vorne.

Das ist aber ein klassisches Eigentor, Windows wurde in Pascal
geschrieben. Mit der Umstellung auf die C-Familie wurde das dann
deutlich besser.

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
--
The modern conservative is engaged in one of man's oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith

 

[Hans-Peter Diettrich]

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

> Mensch, wenn die nur mal alle auf dich hĂśren wĂźrden, oh erleuchteter

DoDi

 

[Johannes Bauer]

On 22.08.19 00:12, Hanno Foest wrote:

Am 21.08.19 um 23:55 schrieb Johannes Bauer:

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.

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.

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

 

[Alfred Gemsa]

Am 21.08.2019 um 23:41 schrieb Johannes Bauer:

Quatsch, in Delphi kannst du auch *jede* Schweinerei kodieren,

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.

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.

nur es
geht da auch so, dass Delphi im Gegensatz zu einigen C-Programmen nicht
als "Write-Only-Language" daherkommt.

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

Mozart ist besser als Katzenjammer ;-)

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

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

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).

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

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.

Da hast du leider recht.

Gruß, Alfred.

 

[Hanno Foest]

Am 21.08.19 um 23:55 schrieb Johannes Bauer:

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.

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
--
The modern conservative is engaged in one of man's oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith

 

[Johannes Bauer]

On 21.08.19 23:25, Hans-Peter Diettrich wrote:

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.

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

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.

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"

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

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?

Jede Programmiersprache hat Nachteile und bei Pascal gibt es aufgrund
des Aufbau des Compilers einige wenige Anweisungen, die z.B. als sich
selbst modifizierendes Programm Ăźbersetzt werden. Dies ist sehr
aufwendig und fĂźr Harvard-Architekturen sogar untauglich.

Ja! Danke!

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

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.

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

So wie das Herumreiten auf Benchmarks mit unglaublichem Faktor 500?

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

Viele Grüße,
Johannes

 

[Hanno Foest]

Am 21.08.19 um 22:05 schrieb Johannes Bauer:

Dass es "brauchbar" ist, zeigt, dass der Großteil unserer heutigen
IT-Infrastruktur darauf basiert. Und im Großen und Ganzen prima
funktioniert.

FĂźr bestimmte Werte von "prima".

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).

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.

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?

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?

und bei den Programmiersprachen mit unsicherem Umgang mit
Arbeitsspeicher ist C nun mal ganz weit vorne.

Klar. Und trotzdem wird C nach wie vor sehr häufig verwendet.

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?

Das mit den 70% ist wohl nicht nur bei Microsoft so, stichprobenartig:
"70% of the high-risk bugs in Chrome 44 would have been prevented if
Chrome were written in a memory-safe language instead of C/C++."

Google macht Chrome. Bei Google arbeiten mit Sicherheit viele der
brilliantesten Software-Designer.

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.

Oder, was ich fĂźr wahrscheinlicher halte: Es gibt knallharte GrĂźnde,
warum die diese Abwägung getroffen haben.

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: https://www.youtube.com/watch?v=pW-SOdj4Kkk).

Im Augenblick ist es so, daß Softwarehersteller an Bugs Geld verdienen:
Sie sind ein Grund fßr Serviceverträge, Updates, neue Versionen. Ich bin
mit ziemlich sicher, daß die Softwarelandschaft deutlich anders aussehen
wĂźrde, wenn Bugs die Hersteller Geld *kosten* wĂźrden.

Das mit dem "brauchbar" ist halt so ne Sache. Es tut Dinge, sicher.
Vielleicht sogar schnell. Und wenn man betriebsblind genug ist, sieht
man auch die Kollateralschäden nicht. Obgleich die immer häufiger
kommenden, immer größeren Sicherheitsupdates auch dem Betriebsblindesten
zeigen sollten, daß Sprachen mit bekannten Sicherheitsimplikationen mit
der immer weiter zunehmenden Komplexität der Software nicht so recht
harmonieren.

Das ist genau das undifferenzierte Argument, das mich an der ganzen
Diskussion hier so ärgert: Wer C einsetzt ist einfach nur betriebsblind.

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.

Man stelle sich vor, ich wĂźrde mich in d.s.e hinstellen und sagen:
"Schaut her, das hier ist der BESTE Transistor".

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

*Wenn* ich einen Tip fßr eine gute C-AblÜsung nennen sollte, wäre das
wohl Rust. Die Benchmarks sehen ganz brauchbar aus [1]. Aber ich kenn
das Dings nicht persĂśnlich, und vielleicht ist es lediglich die neueste
Sau, die durchs Dorf getrieben wird: Man wird es sehen. Nur finde ich es
etwas arm, daß wir seit 40 Jahren oder so die gleichen Fehler machen,
obgleich uns Software helfen kĂśnnte, diese Fehler zu vermeiden. Auf
welchem Wege auch immer.

Hanno

[1]
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust.html
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-gpp.html
--
The modern conservative is engaged in one of man's oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith

 

[Johannes Bauer]

On 21.08.19 23:07, Hans-Peter Diettrich wrote:

Am 21.08.2019 um 22:05 schrieb Johannes Bauer:

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.

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

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:

https://attractivechaos.github.io/plb/
http://ptrace.fefe.de/wp/timings2019.txt
https://julialang.org/benchmarks/

Dass C die meistverwendete Programmiersprache ist, kommt auch nur darauf
an, wie man's misst. Auf TIOBE zumindest nur Platz 2, auf GitHub
gemessen definitiv noch weiter unten. Es ist ansich auch gar nicht
definitiert was "meistverwendet" überhaupt heißt, als Laufzeit? Oder
Codezeilen? Oder Anzahl Programmierer?

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

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

 

[Hans-Peter Diettrich]

Am 22.08.2019 um 00:00 schrieb Johannes Bauer:
[...]
<gähn>

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

Wenn Du meinst, daß Pascal Code mehr als 10% langsamer ist als C Code,
dann mach doch selber einen Benchmark, damit ich Deinen Quelltext
zerpflĂźcken kann. Von einem C Programmierer erwarte ich keinen
ordentlichen (vergleichbaren) FORTH oder Pascal Code. Dein
unqualifiziertes Geifern ist fĂźr mich kein Anreiz, Dir irgendwas
beweisen zu wollen.

Mein Argument war ja lediglich, daß C keine brauchbare
Entwicklungsumgebung ist. Wenn Du das auf Benchmarks reduzierst, dann
kannst Du mir nur noch leid tun :-(

Ich habe nicht viel in C programmiert, mein größtes Programm war ein
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