Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Hans-Peter Diettrich Newsgroups: de.sci.electronics Subject: Re: Wirkungsgrad von 100 m RG213U Date: Wed, 20 Sep 2023 11:56:08 +0200 Lines: 77 Message-ID: References: <57a01ea09f8f81f315dd0de99b31f4853d019b7f.camel@bartheld.net> <6508C875.81B09B27@proton.me> <20230919211342.5cf42359@Achmuehle.WOR> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net XC1QRj7dSGDCJfQ0WtsW8QMLvtXWdmYzidxQhmIYWRrndw6UF/ Cancel-Lock: sha1:M/9bAOYlvmewYkLk7GTbbQKlk4E= sha256:067x0/Dkz1IeXHy10JUVy87e7Cl4MwiKkQqHalIsZmc= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <20230919211342.5cf42359@Achmuehle.WOR> Content-Language: de-DE Xref: csiph.com de.sci.electronics:344213 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