Wirkungsgrad von 100 m RG213U...

[Carla Schneider]

Marte Schwarz wrote:

Hallo zusammen,

Kann sein, daÃY der Pico verschwindet, weil für ihn keine Hochsprache da
ist.

Wer schwadroniert hier eigentlich herum? Für den Pi Pico gibts
selbstredend Python. C und C++ gabs auch vom Start weg. Kein
vernünftiger Mensch schreibt ohne Not eine Zeile Assembler mehr.

Assembler braucht man nur fuer die PIO Prozessoren,
nicht fuer die CPU. Die Programme dafuer sind recht klein
weil es nur je 32 Worte Befehlsspeicher gibt fuer die 2 PIOs
die jeweils 4 Prozessoren haben.

 

[Christoph Müller]

Am 18.09.2023 um 23:43 schrieb Carla Schneider:

Der Vorteil der hoeheren Programmiersprachen ist
dass man die Programme beim Wechsel auf andere Hardware weiter verwenden kann.

Habe ein paar Programme in VB6 (Visual Basic) geschrieben. Die Original
CDs sind verschollen. Wie kriegt man nun die Programme mit möglichst
wenig Aufwand in gängigere Hochsprachen? Auf Win10 kriege ich sie
jedenfalls nur teilweise zum Laufen. Deshalb steht der alte Computer
noch immer in meinem Büro.

--
Servus
Christoph Müller
www.astrail.de

 

[Peter Heitzer]

Carla Schneider <carla_schn@proton.me> wrote:

Peter Heitzer wrote:

Helmut Schellong <var@schellong.biz> wrote:
Am 14.09.2023 um 16:17 schrieb Leo Baumann:
Am 14.09.2023 um 16:10 schrieb Helmut Schellong:
Jedoch noch viel ungeeigneter ist Assembler.

Assembler ist für ALLES perfekt geeignet, wenn man es kann.

Assembler ist für ALLES geeignet, aber für fast nichts _perfekt_ geeignet.
Man hat z.B. Zugang zu allen Instruktionen, die der Compiler nicht verwendet.
Assembler ist _keine_ strukturierte Programmiersprache mit übersichtlichem Quell-Code.
Mittels Makros kann man durchaus übersichtlichen Assemblercode schreiben.
Andererseits kann man in jeder höheren Programmiersprache auch
unübersichtlichen und kaum wartbaren Code schreiben.

Der Vorteil der hoeheren Programmiersprachen ist
dass man die Programme beim Wechsel auf andere Hardware weiter verwenden kann.

Sofern man beim Programmieren auf Portabilität geachtet hat, was durchaus
nicht trivial ist. Byteorder, Zeigergrösse und Alignment können z.B. auf der
anderen Hardware unterschiedlich sein.

--
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de

 

[Hans-Peter Diettrich]

On 9/19/23 12:00 AM, Carla Schneider wrote:

Rolf Bombach wrote:

Den ersten Editor wirst du mit Assembler oder gar in Maschinensprache
schreiben müssen, und zwar ohne Editor :-]

Den allerersten, aber der ist ja schon da.
D.h. man wird fuer eine neue Art Prozessor erst mal einen existierenden Compiler
auf einem existierenden Computer modifizieren so dass er Code fuer den neuen Prozessor
erzeugt, und damit existiernde Software einschliesslich des Compilers und Editors
fuer den neuen Prozessor uebersetzen.

Kein Problem, denn für solche Fälle bietet sich Forth an. Dort hat man
auch einen Editor, der nicht in Maschinensprache geschrieben werden mußte.

Wer firmeninterne Programmiersprachen wie VB für dauerhafte Software
benutzt, der hat sowieso etwas falsch gemacht. Andererseits ist C zwar
sehr weit verbreitet, aber nicht unbedingt zur Portierung von Software
auf andere Plattformen geeignet. Dafür wäre Python und andere
Interpreter-Sprachen ideal, insbesondere im Hinblick auf die vielen
Linux-Varianten. Dann muß ein Interpreter für jedes Zielsystem nur
einmal angepaßt werden, und schon laufen alle Programme auch auf diesem
System. Zwar wären .NET Programme weit effizienter, doch auch da ist die
Verfügbarkeit eher zweifelhaft.

DoDi

 

[Carla Schneider]

Helmut Schellong wrote:

Am 14.09.2023 um 17:37 schrieb Peter Heitzer:
Helmut Schellong <var@schellong.biz> wrote:
Am 14.09.2023 um 16:17 schrieb Leo Baumann:
Am 14.09.2023 um 16:10 schrieb Helmut Schellong:
Jedoch noch viel ungeeigneter ist Assembler.

Assembler ist für ALLES perfekt geeignet, wenn man es kann.

Assembler ist für ALLES geeignet, aber für fast nichts _perfekt_ geeignet.
Man hat z.B. Zugang zu allen Instruktionen, die der Compiler nicht verwendet.
Assembler ist _keine_ strukturierte Programmiersprache mit übersichtlichem Quell-Code.

Mittels Makros kann man durchaus übersichtlichen Assemblercode schreiben.
Andererseits kann man in jeder höheren Programmiersprache auch
unübersichtlichen und kaum wartbaren Code schreiben.

Obwohl das prinzipiell so ist, liegt dadurch jedoch kein Grund vor, ab jetzt wieder
hauptsächlich in Assembler zu programmieren.

Die Sprachmittel einer höheren Programmiersprache sind den Sprachmitteln des Assemblers
haushoch überlegen, so daÃY sehr viel schneller, viel sicherer und übersichtlicher
Code geschrieben werden kann.
Zum Beispiel mit der Multitasking-Sprache PEARL.

\"Process and experiment automation realtime language\"

Das ist eine Sprache fuer Computer die technische Prozesse in Echtzeit steuern
und regeln.

Warum gibt es denn eine groÃYe Anzahl höherer Programmiersprachen?

Weil alle hoeheren Programmiersprachen Wuensche offen lassen, bis heute.
Und so werden immer neue erfunden.

> Und warum wird vielleicht nur zu 0,01% in Assembler programmiert?

Weil man das nur dort tut wo es unbedingt noetig ist, z.B. weil
es nicht anders geht, oder weil man irgenwo das letzte an Geschwindigkeit
herausholen will.

 

[Carla Schneider]

Peter Heitzer wrote:

Carla Schneider <carla_schn@proton.me> wrote:
Peter Heitzer wrote:

Helmut Schellong <var@schellong.biz> wrote:
Am 14.09.2023 um 16:17 schrieb Leo Baumann:
Am 14.09.2023 um 16:10 schrieb Helmut Schellong:
Jedoch noch viel ungeeigneter ist Assembler.

Assembler ist für ALLES perfekt geeignet, wenn man es kann.

Assembler ist für ALLES geeignet, aber für fast nichts _perfekt_ geeignet.
Man hat z.B. Zugang zu allen Instruktionen, die der Compiler nicht verwendet.
Assembler ist _keine_ strukturierte Programmiersprache mit übersichtlichem Quell-Code.
Mittels Makros kann man durchaus übersichtlichen Assemblercode schreiben.
Andererseits kann man in jeder höheren Programmiersprache auch
unübersichtlichen und kaum wartbaren Code schreiben.

Der Vorteil der hoeheren Programmiersprachen ist
dass man die Programme beim Wechsel auf andere Hardware weiter verwenden kann.
Sofern man beim Programmieren auf Portabilität geachtet hat, was durchaus
nicht trivial ist. Byteorder, Zeigergrösse und Alignment können z.B. auf der
anderen Hardware unterschiedlich sein.

Das sollte man normalerweise gar nicht merken, ausser beim Einlesen von binaeren Daten,
wenn man sich umstaendliches Programmieren spart weil die Byteordnung zufaellig stimmt.

 

[Carla Schneider]

Wolfgang Allinger wrote:

On 14 Sep 23 at group /de/sci/electronics in article 65030B64.5E911991@Berger-Odenthal.De
Spam@Berger-Odenthal.De> (Axel Berger) wrote:

Wolfgang Allinger wrote:
ib@leobaumann.de> (Leo Baumann) wrote:
Ich hätte den vorhandenen Assembler gewählt ...
Um nen TextEditor zu schreiben?

Du kennst den legendären und unvergessenen Tempus für Atari
NEIN

oder hast
wenigstens einmal von ihm gehört?
NEIN

Es hat sehr lange gedauert, bis für
DOS und Windows etwas auch nur halbwegs gleichwertiges erschien.

Nein, nix dergleichen.

Ich hab 1971 auf hp 2108, 2114 und dann auf 2100 weitergemacht.
Da war von DOS, CP/M noch lange nix zu sehen.

Merke gerade. dass ich den workflow völlig vergessen habe

Alles nur TTY (ASR-33), LS-Leser und Facit Stanzer... und nen hp 21xx.
und viel Gummi Arabica um LS zusammenzukleben

Danach dann 8080. Bin damals von Wuppertal zur AEG Frankfurt gefahren und
hab dort meine Source Lochstreifen in eine TR440 füttern (lassen).

Mein erster Programm-Text Editor waren die Lochkarten fuer die
TR440, das war 1980. Das ging eigentlich recht gut weil man die Zeilen in denen man
einen Fehler hatte leicht austauschen konnte. Wie das auf Lochstreifen gegangen ist
war mir ein Raetsel, auch wieso man auf dieser Maschine vorher Lochstreifen verwendet hat,
denn die erste TR440 war 1969, Lochkarten sind viel aelter.

Deren TR440 X-Assembler hatte mehr Fehler, als ein Strassenköter Flöhe auf
dem Fell. Wenn man nach einer halben Stunde seine Ergebnisse (Listings und
LS) abholte, und der Weisskittel dann ein Listing mit 200 Seiten
Speicherdump lieferte, wusste ich, dass ich mal wieder einen neuen bug
gefunden habe und das dann wieder in mehrstündigen Diskussionen mit den
Gurus verhackstücken musste.

Mindestens 10x durchexerziert. Immer gewonnen

Dann kam (1976?) endlich ein 8080 Entwicklungssystem von einen Stuttgarter
Ing-Büro, der auch einen Editor und Linker an Bord hatte.

Die TR440 hatte 1980 auch Bildschirmarbeitsplaetze und
es gab dort einen Texteditor mit Namen \"Korrigiere\".
Es gab Algol60, Pascal,Fortran und diverse andere Sprachen.
Pascal wurde fuer die Uebungen der Informatik-Vorlesung
verwendet.
Jetzt habe ich gelesen dass es fuer die TR400 auch eine Maus gab,
die habe ich nicht gesehen, war aber auch nie an einem Graphik-Terminal.
Leider war diese deutsche Computerentwicklung ein totes Ende.

Danach wars deutlich einfacher.

Das erste Terminal, was ich zur Arbeit bekam, war 1978 an einer PDP 11/34,
RSX 11/M mit dem tollen SEDT, wie ich schrub, IMHO einer der besten
Editoren.
Und Ende mit der LS-Flickerei.
Bis Ende 95 auch auf PC benutzt.

Entwicklungssysteme von Mostek Z80 (unter CP/M)

 

[Helmut Schellong]

Am 19.09.2023 um 09:14 schrieb Peter Heitzer:

Carla Schneider <carla_schn@proton.me> wrote:
Peter Heitzer wrote:

Helmut Schellong <var@schellong.biz> wrote:
Am 14.09.2023 um 16:17 schrieb Leo Baumann:
Am 14.09.2023 um 16:10 schrieb Helmut Schellong:
Jedoch noch viel ungeeigneter ist Assembler.

Assembler ist für ALLES perfekt geeignet, wenn man es kann.

Assembler ist für ALLES geeignet, aber für fast nichts _perfekt_ geeignet.
Man hat z.B. Zugang zu allen Instruktionen, die der Compiler nicht verwendet.
Assembler ist _keine_ strukturierte Programmiersprache mit übersichtlichem Quell-Code.
Mittels Makros kann man durchaus übersichtlichen Assemblercode schreiben.
Andererseits kann man in jeder höheren Programmiersprache auch
unübersichtlichen und kaum wartbaren Code schreiben.

Der Vorteil der hoeheren Programmiersprachen ist
dass man die Programme beim Wechsel auf andere Hardware weiter verwenden kann.

Sofern man beim Programmieren auf Portabilität geachtet hat, was durchaus
nicht trivial ist. Byteorder, Zeigergrösse und Alignment können z.B. auf der
anderen Hardware unterschiedlich sein.

Sehr relevant ist die Byteorder!
Das ist ein echtes Problem.
Man kann sich nämlich kaum erlauben, dies (auf uC) portabel zu programmieren!
Code-Größe und -Geschwindigkeit sind einfach zu wichtig.

Zeigergröße und Alignment waren bei mir nie problematisch.
Wenn \'int *ap;\' vereinbart wird, nimmt jeder C-Compiler das korrekte Adressenformat.
Ein C-Compiler verwendet generell ein 2..4..8..16-Byte-Alignment, je nach Ebene und API.
Der legt auch ein char[array] _nicht_ mit 1-Byte-Alignment an, sondern eher mit 4..8 Byte.
Der nimmt einfach das für die jeweilige Plattform passende Alignment.
Aufpassen muß man auf \'int\' :: \'long\'.
Sobald ein Inhalt >2^16-1 werden kann, muß \'long\' genommen werden. Oder int32_t.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 19.09.2023 um 13:06 schrieb Carla Schneider:

Helmut Schellong wrote:

Am 14.09.2023 um 17:37 schrieb Peter Heitzer:
Helmut Schellong <var@schellong.biz> wrote:
Am 14.09.2023 um 16:17 schrieb Leo Baumann:
Am 14.09.2023 um 16:10 schrieb Helmut Schellong:
Jedoch noch viel ungeeigneter ist Assembler.

Assembler ist für ALLES perfekt geeignet, wenn man es kann.

Assembler ist für ALLES geeignet, aber für fast nichts _perfekt_ geeignet.
Man hat z.B. Zugang zu allen Instruktionen, die der Compiler nicht verwendet.
Assembler ist _keine_ strukturierte Programmiersprache mit übersichtlichem Quell-Code.

Mittels Makros kann man durchaus übersichtlichen Assemblercode schreiben.
Andererseits kann man in jeder höheren Programmiersprache auch
unübersichtlichen und kaum wartbaren Code schreiben.

Obwohl das prinzipiell so ist, liegt dadurch jedoch kein Grund vor, ab jetzt wieder
hauptsächlich in Assembler zu programmieren.

Die Sprachmittel einer höheren Programmiersprache sind den Sprachmitteln des Assemblers
haushoch überlegen, so daÃY sehr viel schneller, viel sicherer und übersichtlicher
Code geschrieben werden kann.
Zum Beispiel mit der Multitasking-Sprache PEARL.

\"Process and experiment automation realtime language\"

Das ist eine Sprache fuer Computer die technische Prozesse in Echtzeit steuern
und regeln.

Während meines Studiums programmierte ich ausschließlich mit PEARL.
Der Rechner war von Krupp-Atlas, aus zwei Schränken bestand dessen Kern.

Leider braucht man dazu ein BS RTOS-UH, auf dem ein PEARL-Compiler läuft.
UH ist eine Abkürzung von Universität Hannover.
RTOS-UH braucht eine Plattform Motorola 68xxx oder PowerPC.

PEARL ist aber sehr interessant hinsichtlich Multitasking.
Sie ersetzt vollkommen die in C notwendigen etwa 50 schrecklichen Thread-Funktionen.

====================================================================
Fortschritt: TASK PRIORITY 3; <Body> END;

ACTIVATE Fortschritt;
TERMINATE Kontrolle;
SUSPEND Ausgabe;
CONTINUE Register;
AFTER 5 SEC RESUME;

WHEN Komplett ACTIVATE Kontrolle; /*<Komplett> ist ein IRPT*/

AT 12:0:0 EVERY 30 MIN UNTIL 15:0:0 ACTIVATE Protokoll;

SEMA BOLT /*Variablen-Typen zur Synchronisation von TASKs.*/

RKI: DIGOUT(3) * (2:9) ->
WRITE Ausgabe TO RKI;
====================================================================

Vorstehend wird deutlich, wie übersichtlich und vielfältig Multitasking programmiert werden kann.
Man sollte neben C, C++, C#, eine Multitasking-Sprache \'C&\' kreieren.
Da es die nicht gibt, betreibe ich ersatzweise Multiprocessing.

Warum gibt es denn eine groÃYe Anzahl höherer Programmiersprachen?

Weil alle hoeheren Programmiersprachen Wuensche offen lassen, bis heute.
Und so werden immer neue erfunden.

Und warum wird vielleicht nur zu 0,01% in Assembler programmiert?

Weil man das nur dort tut wo es unbedingt noetig ist, z.B. weil
es nicht anders geht, oder weil man irgenwo das letzte an Geschwindigkeit
herausholen will.

Oben schrieb ich: \"Jedoch noch viel ungeeigneter ist Assembler.\"
Die Antwort oben: \"Assembler ist für ALLES perfekt geeignet, wenn man es kann.\"

Nur _deshalb_ schrieb ich die vorstehenden beiden Sätze als Antwort darauf.

--
Mit freundlichen Grüßen
Helmut Schellong

 

[Volker Bartheld]

On Tue, 2023-09-19 at 00:57 +0200, Carla Schneider wrote:

Volker Bartheld wrote:
On Thu, 2023-09-14 at 17:27 -0400, Wolfgang Allinger wrote:
BTW ich bin Bitpopler der ersten Stunden, also absoluter HardCore 
Assembler Programmierer. Ich käme nie auf die Idee, einen Editor in 
Assembler zu schreiben. Assembler ist für high speed, nix für
lahmarschige Menschen, die an einer Klapperatur sitzen.
Na, dann sag mir doch mal, welche Hochsprachen Du für einen Editor z. B. auf
einem Sinclair ZX Spectrum verwenden würdest. Wo wir doch bei Bitpopeln in
der Gründerzeit angelangt sind.
Heute wuerde man einen C-Compiler fuer Z80 verwenden, ich weiss aber nicht
seit wann es den gibt. Was es damals sicher gab war BASIC.

Einen \"Editor\" in BASIC schreiben? Ja, das geht natürlich. Schließlich habe ich
ja formal ein ganzes Rollenspiel mit KI-Charakteren, GUI und lustigen Bildchen
dazu:

https://www.rickdangerous.co.uk/csscgc2021/reviewbonus1.html
https://worldofspectrum.net/item/0034706/

in BASIC geschrieben. Vor ein paar Jahrzehnten. Mehr oder weniger erfolgreich.

Und ebenso natürlich haben die Buben von Ultimate, Bug Byte, Quicksilva & Co die
Spiele meist nicht auf der Gummitastatur entwickelt, den Z80-Schmöker von Rodnay
Zaks [1] nebendran und die Flußdiagramme auf Zettelchen aufgemalt, so wie ich.

Der sich einen Knopf ans Ohr freute, als endlich HiSoft Devpac [2] mit einem
ordentlichen (Dis)Assembler auf den Markt kam - mit Editor in Z80-Assembler
natürlich, der in den oberen 32kB(!) RAM wohnen konnte, wo man voller
Angstschweiß sündteure 64kBit-ICs eingelötet hatte. Statt der 32kBit-
Ausschußware, die Sparfuchs Sir Clive damals ergattert hatte [3].

Diese Bänke konnte man dann mit einem Schalter, selbstgelöteter Z80-PIO oder dem
Multiface One hin und herschalten, mußte also nicht DevPac nervtötend von
Kassette (oder Microdrive) laden, falls der eigene Code abgesemmelt war. Denn
den Luxus von ISP-Debugging war zu dem Zeitpunkt für Hobbyisten nur ein ziemlich
feuchter Traum.

Matthew Smith [4], Schöpfer der epischen Spiele Manic Miner und Jetset Willy,
hoch aufgestiegen und tief gefallen, hat sein ZX Spectrum Cross-Development Rig
von denselben Leuten gekriegt, die auch das Team von Sir Clive für die
Entwicklung vom Sinclair BASIC (und später auch der IF1 Firmware) versorgten.
Eine oberhalb von £60\'000 angesiedelte DEC VAX 11/780 [5].

Man munkelt auch, daß Manic Miner die ersten Gehversuche auf einem TRS-80 [6]
machte, damit das Spiel rechtzeitig zum Release des Spectrum fertig wurde [7].

Ultimate (Pssst!, Cookie, Jetpac, Jetman, Atic Atack) beschritt schon damals
einen zum typischen Kinderzimmer-Coder deutlich verschiedenen Weg, mit einer
Multiuser-32-Bit-Workstation (vermutlich 68000), wo man für die Z80-
Zielplattform crosscompilieren konnte [8].

Bei Hewson hatte man 1988 dem Vernehmen nach bereits IBM PC mit Z80
Crossassembler, der 200k Sourceode in wenigen Sekunden verdauen und ihn via
Parallelport rüberschicken konnte.

Den letzten Schliff habe ich \"Ring of the Inka\" natürlich mit EightyOne, FUSE,
Bas2Tap, BinTap auf dem PC gegeben. Sonst würde man komplett wahnsinnig werden,
mit dem verkrüppelten Einzeileneditor in 16k ROM ohne jegliche Such-
/Ersetzfunktion.

In Sachen \"Editor\" dürfte wohl Tasword Two von Tasman Software das Maß der Dinge
darstellen [9], mangels Details kann ich nur vermuten daß man auch dort bestimmt
nicht Hexcodes in ein BASIC-Listing eingetippt hat, wie es zu Zeiten von \"Your
Spectrum\" [10] [11] oder \"Your Sinclair\" [12] gang und gäbe war.

Deinen Spruch \"Was es damals sicher gab war BASIC.\" finde ich vor diesem
Hintergrund also schon einigermaßen amüsant, \"Ich käme nie auf die Idee, einen
Editor in Assembler zu schreiben.\" grenzt bereits an Schwachsinn.

Volker

[1] https://archive.org/details/Programming_the_Z-80_2nd_Edition_1980_Rodnay_Zaks
[2] https://worldofspectrum.org/archive/software/utilities/hisoft-devpac-hisoft
[3] https://de.wikipedia.org/wiki/Sinclair_ZX_Spectrum#Hardware
[4] https://www.youtube.com/watch?v=LymCezUg7HI
[5] https://www.zdnet.com/article/the-zx-spectrum-birthday-memories/
[6] https://en.wikipedia.org/wiki/TRS-80
[7] https://skoolkit.ca/disassemblies/manic_miner/reference/facts.html#sourceCodeRemnants
[8] https://www.filfre.net/2014/01/the-legend-of-ultimate-play-the-game/
[9] https://everything2.com/title/Tasword
[10] https://archive.org/details/your-spectrum-magazine
[11] https://worldofspectrum.org/archive/magazines/your-spectrum
[12] https://worldofspectrum.org/archive/magazines/your-sinclair

 

[Sieghard Schicktanz]

Hallo Hans-Peter,

Du schriebst am Tue, 19 Sep 2023 10:14:54 +0200:

Kein Problem, denn für solche Fälle bietet sich Forth an. Dort hat man
auch einen Editor, der nicht in Maschinensprache geschrieben werden mußte.

Der original Editor von FORTH (großgeschrieben) ist ein Festformat-Editor
ohne Zeilenstruktur. Sowas ist natürlich einfach implementierbar, deswegen
wurde so einer auch dafür benutzt.

> Wer firmeninterne Programmiersprachen wie VB für dauerhafte Software

Genau genommen ist \"VB\" (als \"Visual Basic\" interpretiert) nur eine IDE für
einen allerdings spzifischen Dialekt eines fortgeschrittenen Basic (nein,
hier nicht großgeschrieben, weil das nicht mehr das Original war) mit der
Möglichkit, gar dem Zwang, zu etwas ähnlichem wie strikturierter
Programmierung, d.h. echte Bedingungen, Schleifen und sogar Subroutinen als
syteaktische Elemente.

benutzt, der hat sowieso etwas falsch gemacht. Andererseits ist C zwar
sehr weit verbreitet, aber nicht unbedingt zur Portierung von Software

Was niemand davon abhält, es für genau den Zweck mit weitester Verbreitung
einzusetzen. Allerdings ist C sowieso keine Programmiersprache, allenfalls
ein Zerrbild einer solchen.

auf andere Plattformen geeignet. Dafür wäre Python und andere
Interpreter-Sprachen ideal, insbesondere im Hinblick auf die vielen

Wobei sich hier wieder dir Frage aufwirft, wo das Ei sein Huhnauf dem
Zielsystem finden soll - d.h. eine Interpretersprache kann man erst auf
einem Zielsystem benutzen, wenn man dort schon den dazugehörigen
Interpreter hat.

> Linux-Varianten. Dann muß ein Interpreter für jedes Zielsystem nur

Ja, da ist Linux natürlich besonders variabel, das hat überall weitgehend
dieseleb Struktur, dieselben Bibliotheken (evtl. in unterschiedlichen
Versionen) und dieselben Systemanwendungen. Da ist Windows viel einfacher,
da hat nur jede Version ihre eigenen, teilweise (bedienungs-) inkompatiblen
Systemprogramme.

einmal angepaßt werden, und schon laufen alle Programme auch auf diesem
System. Zwar wären .NET Programme weit effizienter, doch auch da ist die
Verfügbarkeit eher zweifelhaft.

Ja, \".NET\". Nett... gedacht, aber mit seinen ganzen, auch wieder teilweise
inkompatiblen Varianten eher ein Sauhaufen und Born an Frustration für den
Programmierer, der nicht \"von Null anfangen\" kann.
Aber stimmt schon, Python entwickelt sich mit seinem Modul-Zoo auch schon
sehr in die Richtung von Perl, das es als einzige Programmiersprache bisher
fertigbringt, bei Aktualisierungen einiger seiner Module zu scheitern, weil
die schon vorhanden sind.. (Auch wenn es dabei eher um fremdkompilierte
externe Objekt-Module geht.)

Fazit: Systemunabhängigkeit wäre zwar öfters mal sehr nett, ist aber nicht.

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Hans-Peter Diettrich]

On 9/19/23 9:13 PM, Sieghard Schicktanz wrote:

Hallo Hans-Peter,

benutzt, der hat sowieso etwas falsch gemacht. Andererseits ist C zwar
sehr weit verbreitet, aber nicht unbedingt zur Portierung von Software

Was niemand davon abhält, es für genau den Zweck mit weitester Verbreitung
einzusetzen.

Das ist nicht ganz richtig. Tatsächlich legt der Hersteller einer
portablen Software mit Autobloat fest, auf welchen Zielsystemen sie
lauffähig sein soll. (siehe unten)

Allerdings ist C sowieso keine Programmiersprache, allenfalls
ein Zerrbild einer solchen.

Ein High-Level Assembler aus einem Konglomerat von mehreren Sprachen.

auf andere Plattformen geeignet. Dafür wäre Python und andere
Interpreter-Sprachen ideal, insbesondere im Hinblick auf die vielen

Wobei sich hier wieder dir Frage aufwirft, wo das Ei sein Huhnauf dem
Zielsystem finden soll - d.h. eine Interpretersprache kann man erst auf
einem Zielsystem benutzen, wenn man dort schon den dazugehörigen
Interpreter hat.

Wobei es im Interesse der Pfleger eines solchen Systems liegen sollte,
solche Interpreter zum Lieferumfang des Systems zu machen. Bei Autobloat
ist es genau umgekehrt, da liegt es im (Des-)Interesse des
Programmierers, auf welchen Zielsystemen sein Programm lauffähig sein soll.

Linux-Varianten. Dann muß ein Interpreter für jedes Zielsystem nur

Ja, da ist Linux natürlich besonders variabel, das hat überall weitgehend
dieseleb Struktur, dieselben Bibliotheken (evtl. in unterschiedlichen
Versionen) und dieselben Systemanwendungen.

Gerade die Bibliotheken unterliegen einem ständigen Update, das eine
ebenso ständige Anpassung der Software erfordern kann, die auf dem
jeweiligen Linux laufen sollen.

Da ist Windows viel einfacher,
da hat nur jede Version ihre eigenen, teilweise (bedienungs-) inkompatiblen
Systemprogramme.

Auch da ändern sich die Systembibliotheken und Anforderungen an
Programme mit jeder neuen Version. Es gibt allerdings nur eine geringe
Anzahl von Versionen, die eine Software gleichzeitig unterstützen muß,

einmal angepaßt werden, und schon laufen alle Programme auch auf diesem
System. Zwar wären .NET Programme weit effizienter, doch auch da ist die
Verfügbarkeit eher zweifelhaft.

Ja, \".NET\". Nett... gedacht, aber mit seinen ganzen, auch wieder teilweise
inkompatiblen Varianten eher ein Sauhaufen und Born an Frustration für den
Programmierer, der nicht \"von Null anfangen\" kann.

Am übelsten ist die Borniertheit der Entwickler, die ein angeblich
offenes System weitgehend geheim gehalten haben und damit die Portierung
auf andere Plattformen als Windows torpediert haben. Viel einfacher kann
man sich nicht ins Knie schießen :-]

Aber stimmt schon, Python entwickelt sich mit seinem Modul-Zoo auch schon
sehr in die Richtung von Perl, das es als einzige Programmiersprache bisher
fertigbringt, bei Aktualisierungen einiger seiner Module zu scheitern, weil
die schon vorhanden sind.. (Auch wenn es dabei eher um fremdkompilierte
externe Objekt-Module geht.)

Fazit: Systemunabhängigkeit wäre zwar öfters mal sehr nett, ist aber nicht.

So ist das (un)wohl
DoDi

 

[Bernd Laengerich]

Am 16.09.2023 um 23:40 schrieb Rolf Bombach:

Fortran war halt _der_ Durchbruch, 1957(!).

Da muß ich doch aus von Lutz Donnerhacke zusammengetragenen \"Fachbegriffen der
Informatik\" zitieren.:

\"FORTRAN ist älter als jeder Lötkolben, ist klobiger als jede Elektronenröhre
und unpraktischer als Würfelzucker in Tuben. Ein streunender Kater, der nach
einem nächtlichen Gesangsauftritt mit dem Inhalt eines Nachttopfs übergossen
wurde, ist verglichen mit einem Stück FORTRAN77-Sourcecode eine ausnehmend
elegante Erscheinung. Nun, immerhin kann FORTRAN die vier Grundrechenarten. \"
(Nico Hoffmann)

Bernd

 

[Helmut Schellong]

Am 20.09.2023 um 11:56 schrieb Hans-Peter Diettrich:

On 9/19/23 9:13 PM, Sieghard Schicktanz wrote:
Hallo Hans-Peter,

benutzt, der hat sowieso etwas falsch gemacht. Andererseits ist C zwar
sehr weit verbreitet, aber nicht unbedingt zur Portierung von Software

Was niemand davon abhält, es für genau den Zweck mit weitester Verbreitung
einzusetzen.

Das ist nicht ganz richtig. Tatsächlich legt der Hersteller einer portablen Software mit Autobloat
fest, auf welchen Zielsystemen sie lauffähig sein soll. (siehe unten)

Allerdings ist C sowieso keine Programmiersprache, allenfalls
ein Zerrbild einer solchen.

Da Assembler eine Programmiersprache ist, kann nicht behauptet werden, C sei keine.

> Ein High-Level Assembler aus einem Konglomerat von mehreren Sprachen.

Daß C auch ein High-Level-Assembler ist, kann gesagt werden.
Als Konglomerat von mehreren Sprachen kann sie nicht bezeichnet werden, denn
es gibt praktisch keine Sprache, die nicht auf irgendwelchen früheren Sprachen basiert.

C basiert auf B; Der Entwickler von C mitentwickelte zuvor B.
B wiederum basiert auf BCPL (vor Unix).
Der Zeitstempel von Unix mit dem Wert 0 ist dem \'01.01.1970 00:00:00\' zugeordnet.
C wurde eben _wegen_ Unix entwickelt, um den Unix-Kernel fortan in C schreiben zu können.
Dieses Ziel war 1973 erreicht; 1974 erschien C; 1978 gabs ein C-Buch.

Wegen der Zielvorgabe von C (Unix) wurde C mit _sehr vielen_ Freiheiten ausgestattet.
Andernfalls hätte C die Zielvorgabe nicht erreicht und wäre sinnlos gewesen.
Der Nachteil von C sind diese Freiheiten, da die Mehrheit soviel Freiheit nicht verträgt!
In intelligenter und disziplinierter Hand sind C/C++ nicht/kaum zu übertreffen.

Genau deshalb führt das Paar C/C++ unter den Compiler-Sprachen mit wohl 95% Anteil, wobei
eine 3-stellige Anzahl von weiteren Sprachen sich den Rest von etwa 5% teilt.
Fast alle der restlichen Sprachen haben folglich jeweils einen Anteil von weit unter 1%.
So ist die aktuelle Realität.

Es gibt schon lange den zutreffenden Ausspruch: \"An C/C++ kommt man nicht vorbei!\".
Wer sich da herumdrückt, ist in den meisten Fällen beruflich nahezu völlig abgehängt.
Ganz schlecht für C-Hasser.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Hartmut Kraus]

Am 20.09.23 um 16:27 schrieb Helmut Schellong:
> Es gibt schon lange den zutreffenden Ausspruch: \"An C/C++ kommt man nicht vorbei!\".

Nö.

\"C ist ein offener Geländewagen. Du kommst durch jeden Dreck, aber siehst hinterher entsprechend aus.\"
\"Einem C-Compiler kann man Goethes \'Faust\' vorsetzen, und er wird nichts weiter ausgeben als ein paar Warnungen.\"

Gab noch mehr solche Sprüche, finde sie aber nicht mehr. Schade, hätte ich aus meinem Weiterbildungslehrgang damals aufheben sollen.

Wer sich da herumdrückt, ist in den meisten Fällen beruflich nahezu völlig abgehängt.
Ganz schlecht für C-Hasser.

Richtig, C muss man lieben. Aber wenn ich das richtig sehe, gehört die \"digitalisierte\" Welt doch den Interpretersprachen - läuft denn z.B. irgendwas im Netz heute noch ohne PHP ...

--
\"Man sollte keine Dummheit zweimal begehen, die Auswahl ist schließlich groß genug.\" (Jean-Paul Sartre)

https://hkraus.eu/hk/Profil.pdf

 

[Marte Schwarz]

Ach Kinders,

Richtig, C muss man lieben. Aber wenn ich das richtig sehe, gehört
die \"digitalisierte\" Welt doch den Interpretersprachen - läuft denn z.B.
irgendwas im Netz heute noch ohne PHP ...

Es gibt unterschiedliche Anwendungen, die programmiert werden. Je nach
Anwendung nutzt man dann die Tools/ Programmiersprache, die dafür
geeignet ist. Interpretersprachen sind weder prinzipiell besser noch
schlechter. Häufig sind sie einfach zu langsam. Da sind compilierte
Programme im Vorteil.

Eine \"digitalisiete\" Welt gibts nicht wirklich. PHP hat seinen Platz an
ganz anderen Stellen, als im 4- bis 16-Bit µC Bereich ist das ist eine
ganz andere \"digitalisierte\" Welt, als mit 32/ 64
Bit-Multicore-µC-Bereich, mit denen Multimedia-Konsolen und vieles mehr
programmiert wird. Eine Spezialanwendung an einem Prüf- oder
Forschungsplatz wird mit anderen Anforderungen laufen müssen/dürfen, als
bei einem Massenprodukt. Beim einen dürften Hardwarebeschränkungen keine
Rolle spielen, man nimmt eben mehr Rechenleistung und gut. Beim anderen
zählt jedes Cent und man spart an Speicher und Rechenleistung wo immer
es geht.

Kein vernünftiger Programmierer wird ein Massenprodukt mit 4/8-Bit µC
mit PHP oder Python programmieren. Genausowenig wird man eine
Webanwendung mit C interaktiv gestalten wollen.
All diese Ebenen in einen Topf zu werfen und dann zu behaupten, 95 %
aller Programme seien C/C++ ist einfach Unsinn, zumal die Basis nicht
definiert wurde. Was sollen denn 100 % sein? Anzahl der geschriebenen
Codezeilen, ausgelieferte Stück Hardware, im zeitlichen Mittel laufender
Code ... ?

Just my 2 ct

Marte

 

[Holger Schieferdecker]

Am 20.09.2023 um 21:55 schrieb Hartmut Kraus:

Am 20.09.23 um 16:27 schrieb Helmut Schellong:
Es gibt schon lange den zutreffenden Ausspruch: \"An C/C++ kommt man
nicht vorbei!\".

Nö.

\"C ist ein offener Geländewagen. Du kommst durch jeden Dreck, aber
siehst hinterher entsprechend aus.\"
\"Einem C-Compiler kann man Goethes \'Faust\' vorsetzen, und er wird nichts
weiter ausgeben als ein paar Warnungen.\"

Gab noch mehr solche Sprüche, finde sie aber nicht mehr. Schade, hätte
ich aus meinem Weiterbildungslehrgang damals aufheben sollen.

Mir sind mal noch die folgenden begegnet:

Das letzte Schöne, das in C geschrieben wurde, war Schuberts 9. Sinfonie.

C is a language that combines all the elegance and power of
assembly language with all the readability and maintainability
of assembly language.

Holger

 

[Hartmut Kraus]

Am 21.09.23 um 09:57 schrieb Holger Schieferdecker:

Am 20.09.2023 um 21:55 schrieb Hartmut Kraus:
Am 20.09.23 um 16:27 schrieb Helmut Schellong:
Es gibt schon lange den zutreffenden Ausspruch: \"An C/C++ kommt man nicht vorbei!\".

Nö.

\"C ist ein offener Geländewagen. Du kommst durch jeden Dreck, aber siehst hinterher entsprechend aus.\"
\"Einem C-Compiler kann man Goethes \'Faust\' vorsetzen, und er wird nichts weiter ausgeben als ein paar Warnungen.\"

Gab noch mehr solche Sprüche, finde sie aber nicht mehr. Schade, hätte ich aus meinem Weiterbildungslehrgang damals aufheben sollen.

Mir sind mal noch die folgenden begegnet:

Das letzte Schöne, das in C geschrieben wurde, war Schuberts 9. Sinfonie.

C is a language that combines all the elegance and power of
assembly language with all the readability and maintainability
of assembly language.

Richtig. \"C ist ein besserer Assembler.\"

--
\"Man sollte keine Dummheit zweimal begehen, die Auswahl ist schließlich groß genug.\" (Jean-Paul Sartre)

https://hkraus.eu/hk/Profil.pdf

 

[Hartmut Kraus]

Am 21.09.23 um 09:57 schrieb Holger Schieferdecker:

Am 20.09.2023 um 21:55 schrieb Hartmut Kraus:
Am 20.09.23 um 16:27 schrieb Helmut Schellong:
Es gibt schon lange den zutreffenden Ausspruch: \"An C/C++ kommt man nicht vorbei!\".

Nö.

\"C ist ein offener Geländewagen. Du kommst durch jeden Dreck, aber siehst hinterher entsprechend aus.\"
\"Einem C-Compiler kann man Goethes \'Faust\' vorsetzen, und er wird nichts weiter ausgeben als ein paar Warnungen.\"

Gab noch mehr solche Sprüche, finde sie aber nicht mehr. Schade, hätte ich aus meinem Weiterbildungslehrgang damals aufheben sollen.

Mir sind mal noch die folgenden begegnet:

Das letzte Schöne, das in C geschrieben wurde, war Schuberts 9. Sinfonie.

C is a language that combines all the elegance and power of
assembly language with all the readability and maintainability
of assembly language.

Nö. \"C sieht aus wie eine Ansammlung von Schreibfehlern.\"

--
\"Man sollte keine Dummheit zweimal begehen, die Auswahl ist schließlich groß genug.\" (Jean-Paul Sartre)

https://hkraus.eu/hk/Profil.pdf

 

[Hartmut Kraus]

Am 21.09.23 um 09:57 schrieb Holger Schieferdecker:

Am 20.09.2023 um 21:55 schrieb Hartmut Kraus:
Am 20.09.23 um 16:27 schrieb Helmut Schellong:
Es gibt schon lange den zutreffenden Ausspruch: \"An C/C++ kommt man nicht vorbei!\".

Nö.

\"C ist ein offener Geländewagen. Du kommst durch jeden Dreck, aber siehst hinterher entsprechend aus.\"
\"Einem C-Compiler kann man Goethes \'Faust\' vorsetzen, und er wird nichts weiter ausgeben als ein paar Warnungen.\"

Gab noch mehr solche Sprüche, finde sie aber nicht mehr. Schade, hätte ich aus meinem Weiterbildungslehrgang damals aufheben sollen.

Mir sind mal noch die folgenden begegnet:

Das letzte Schöne, das in C geschrieben wurde, war Schuberts 9. Sinfonie.

Nein, nein, \"The Day the Music Died\" war doch erst der 3. Februar 1959. Jedenfalls, wenn man Donald McLean III Glauben schenken kann.

--
\"Man sollte keine Dummheit zweimal begehen, die Auswahl ist schließlich groß genug.\" (Jean-Paul Sartre)

https://hkraus.eu/hk/Profil.pdf