Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Hermann Riemann Newsgroups: de.alt.folklore.computer Subject: Re: Accidental Complexity von Programmiersprachen Date: Thu, 9 May 2024 16:03:27 +0200 Lines: 131 Message-ID: References: <8ct11jldc86pbvlrmj190jf0a6grslv3c3@joergwalther.my-fqdn.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net NSO3Q6frMjpjfRnlAJfszgDxitJTzXc4+5ALNhBAuh7vbTAodS Cancel-Lock: sha1:anfEnbZx3lGKTzpEs08dNmQYF4Y= sha256:Xb1ZOX8VcUZbikks4f5KdzJKrsOq9tA0SSTn7dbLi8U= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 In-Reply-To: Content-Language: de-DE Xref: csiph.com de.alt.folklore.computer:44629 Am 09.05.24 um 15:03 schrieb Thomas Koenig: > Hermann Riemann schrieb: >> Am 09.05.24 um 09:31 schrieb Thomas Koenig: >> >>>> Ich habe sehr wenig in Fortran programmiert und das ist lange her (ich >>>> glaube, das war noch nicht mal Fortran 77[1]), >> >> Während meiner Ausbildung habe ich >> für diverse Probleme FORTRAN IV verwendet. >> Während meiner Berufszeit war überwiegend FORTRAN 77 >> mit Erweiterung Strings mit variable Länge ( FOR1 ) >> meine bevorzugte Sprache. > > Hmm... scheint für BS2000 zu sein, korrekt? Ja. Beruflich habe ich fast nur mit BS2000 gearbeitet. Ein wenig mit Unix ( Sinix ) und bei Verwaltungsaufgaben etwas windows. > Ist aber auch > bei Fortran 77 stehengeblieben, genauso wie VS Fortran für die > IBM-Systeme. Bis auf Erweiterungen wie strings mit variabler Länge. >> Und Großbuchstaben. > > War kaum ein Problem, in der Praxis. Namen und Schlüsselwörter mit Kleinbuchstaben kann ich leichter lesen. >> Und (wie Basic) Ziffern statt Namen bei Sprungzielen. >> Sie stammt wie COBOL und LISP aus der Lochkartenzeit, >> in der einige computer keine Kleinbuchstaben konnten. > > FORTRAN wurde für die IBM 704 entwickelt, das war ein 36-bit-System > mit 6-bit-Characters. Daher auch die Beschränkung auf 72 gültige > Spalten: Mehr konnte der Lochkartenleser der 704 nicht auf einmal > einlesen, weil er den Akkumulator und das MQ-Register zeilenweise > vollgeschrieben hat. > >> Die CDC 33000 hatte ein character nur 6 Bit. > > Wie viele andere auch. Erst das System/360 hat das 8-bit-Byte > und Byte-Adressen eingeführt. Heute schwer vorstellbar, was > das für eine Revolution war. Die CDC 3300 hatte 24 Bit Wörter; 4 Buchstaben a 6 Bit. Und 15 Bit Wortadressen. Und ich brauchte Benutzungserlaubnis. die ich dank Kurse erhielt. Mein 12 bit computer ( IM6100, PDP8 kompatibel ) hat nicht funktioniert. >> Fortran 90 habe ich nicht mehr verwendet. >> % statt Punkt bei Strukturen behindert Lesbarkeit. > Das ist einfach Gewöhnung. % stört bei mir das Lesen. ( @ in Perl auch ) >> Zumal ich 1990 auch schon C kannte, >> wo es keine software Einschränkung bei String Länge gab. > > String-Handling war in Fortran tatsächlich etwas umständlich > und ist auch heute, mit allocatable Characters, noch > nicht ganz 100% zufriedenstellend (aber es kann alles, > was man braucht). Die strings mir variabler Länge in Fortann 77 von Siemens (FOR1) waren sehr bequem. >>> Damit hatte C vom Sprachumpfang keinen Vorteil mehr gegenüber >>> Fortran, es sei denn, man braucht unsigned ints (eine ärgerliche >>> Lücke). >> >> Fortran 90 war praktisch eine andere Sprache, > > Mit dem großen Unterschied, dass alte Programme noch laufen. Wie C in C++. > Und das ist auch heute noch ein Riesenvorteil gegenüber den > Sprachen, die alle Jahre wieder Kompatibilität über den > Haufen werfen. Ich sage nur Umstieg von Python 2 auf > Python 3... Python 2 war noch zur relativen Frühzeit von Python. Python 3 ist schon 15 Jahre her. >> FORTRAN ist Spitze bei Numerik + Geschwindigkeit. >> C, auch wenn es nicht zum Sprachstandard gehört, >> bei gewissen Systemaufgaben wie Datei header. > > Vor allem natürlich, wenn die Interfaces in C definiert sind. > Aber seit Fortran 2003 existiert auch in ein in der Norm > definiertes C-Interface. Bei Siemens gab es auch Sprachmix verschiedener Sprachen mit gewissen Einschränkungen durch gemeinsame Unterprogrammschnittstelle. >> Python ist für mich bei Textverarbeitung so bequem >> wie bei keiner anderen Programmiersprache. > Ich bin kein Python-Freund; ich nehme typischerweise Perl > (oder, seit neuestem, Julia). Ich fand Python besser lesbar als Perl. Was kann Julia, was Python nicht kann? Auf dem PC 8 SuSE 15.0) habe ich Julia Version 0.6.2 (2017-12-13) Wenn ich bei Julia das lästige end weglasse, scheint es mir bei normalen Anweisungen wie Python auszusehen. Wenn ich meine aktiven eigenen Programme abschätze, habe ich ca 90% Python3, ca 9% C, ca 5‰ jeweils Javascript und bash. Unter den "ich will vermeiden" Sprachen fallen bei mir Java, Pascal, Ada, COBOL, Perl, Algol*. Unter den "eventuell verwenden" Sprachen am ehesten Rust. Dann wären noch Lisp, Lua, Haskell, C++ Kandidaten Eventuell²: Julia, R, Ruby Meine Lisp (1.5) Erfahrung liegt Jahrzehnte zurück. --