Forum: PC-Programmierung Programmiersprache mit Zukunft


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Vanye R. (vanye_rijan)


Lesenswert?

Liebe Freunde der Programmierung,

tief in uns drin wissen wir natuerlich das die einzige wahre 
Programmiersprache nur "C" sein kann, gelegentlich vielleicht noch in 
ihrem geschwaetzigen Derivat "C++" akzeptiert. Aber ueber lange Zeit 
hinweg gab es verweichlichten Nachwuchs welcher glaubte die Zukunft 
koennte Konstrukten wie "Python", "Rust" oder "Go" gehoeren. Alleine 
schon die Namen, wie mit dem Klammerbeutel gepudert!

Aber das Tal der Traenen ist durchschritten, die aktuelle c't (18/2023) 
welche ihr ab sofort an eurem Kiosk, etwas entfernt von den 
Tittenmagazinen(!), kaufen koennt, enthaelt den ersten Teil eines neuen 
FORTRAN-Kurs!
Endlich werden einem wieder die Freuden einbuchstabiger Variablen wie 
"i" nahegebracht welche den Typ automatisch zugeteilt bekommen. So sieht 
die moderne Programmierung aus!

Auch die Abspeicherung auf Lochkarten wird schonmal erwaehnt. Dabei sehe 
ich gerade dort grosses Potential! Wenn Programme nur so gross sein 
duerfen wie ein Programmierer Lochkarten in einen Schuhkarton bekommt, 
so manches ueble Machwerk der Zunft wuerde uns erspart werden.

Selbst der charmante Titel: "Warum sie jetzt Fortran lernen sollten" 
macht klar das sich dieser Artikel an grenzdebile^Werfolgreiche 
Nachwuchsprogrammierer wendet welche auch sonst die ueblichen "was sie 
jetzt wissen muessen" Artikel unserer hochentwickelten Presse lesen.

Wie sagt mein Mathe Professor anno 95 doch: Seid froh das ihr jetzt 
Fortran lernen duerft! Algol68 war viel schlimmer!

Vanye


p.s: Posting kann Spuren von Ironie enthalten.

von Georg M. (g_m)


Lesenswert?

OK

von Abdul K. (ehydra) Benutzerseite


Lesenswert?

Dann nehme ich dich lieber das andere Magazin. Das veraltet eigentlich 
auch nicht wirklich 😂

von Gerhard O. (gerhard_)


Lesenswert?

Dann hast Du bestimmt noch nicht vom Jacquard computer gehört.

Auf pneumatischer Basis fundierend, erlaubt dieses übersehbare und nicht 
überhörbare Konzept vollkommen EMC gerechtes "Computing". Auch ist das 
Konzept vollkommen EMP sicher. Also bestimmt zukunftsweisend. Ferner, 
vermeidet dieses Konzept die gedankenlose Anhäufung von Elektronik Müll, 
weil es aus umweltfreundlichen natürlichen Materialien aufgebaut werden 
kann, die nachwachsen können. Zur Zeit arbeitet man allerdings noch 
daran, die Zyklenzeiten der Maschine zu verbessern. Auch versucht man 
durch Miniaturisierung den Platzbedarf zu verkleinern. Auch gewisse UI 
Probleme gilt es auszuarbeiten. Jedenfalls besteht große Hoffnung, daß 
durch diese neue Technik, weltweit die immensen Berge von Elektronikmüll 
durch die umweltfreundliche Jaquard Methoden ersetzt werden können.

Duck und weg...

: Bearbeitet durch User
von Norbert (der_norbert)


Lesenswert?

Vanye R. schrieb:
> Auch die Abspeicherung auf Lochkarten wird schonmal erwaehnt.
> Dabei sehe ich gerade dort grosses Potential!
> Wenn Programme nur so gross sein duerfen wie ein
> Programmierer Lochkarten in einen Schuhkarton bekommt,
> so manches ueble Machwerk der Zunft wuerde uns erspart werden.

Nicht zu vergessen die Möglichkeit wichtige Programmstellen mit 
farbenfrohen Prilblumen zu markieren.

von Tilo R. (joey5337) Benutzerseite


Lesenswert?

Norbert schrieb:
> Nicht zu vergessen die Möglichkeit wichtige Programmstellen mit
> farbenfrohen Prilblumen zu markieren.

Das dürfte ja schon daran scheitern, dass die meisten der Jünglinge 
zeitlebens noch keine Prilblume gesehen haben.

von Norbert (der_norbert)


Lesenswert?

Tilo R. schrieb:
> Das dürfte ja schon daran scheitern, dass die meisten der Jünglinge
> zeitlebens noch keine Prilblume gesehen haben.

Kann man nachholen. Einfach schauen wo im Ort ein altes Haus mit der 
Birne abgerissen wird. Meistens bleibt eine Wand bis zum Schluss stehen 
und will einfach nicht umfallen.
Das war die Küche, Fliesenwand, Prilblumen…

: Bearbeitet durch User
von Andreas H. (ahz)


Lesenswert?

Vanye R. schrieb:
> Auch die Abspeicherung auf Lochkarten wird schonmal erwaehnt. Dabei sehe
> ich gerade dort grosses Potential!
Kriegt man da denn kein Speicherplatzproblem? Lochkarten kann man ja 
leider  kaum noch kaufen (waren mal meine Lieblingsnotizzettel).

/regards

von Sebastian W. (wangnick)


Lesenswert?

Ich erinnere mich. COBOL war schlimmer.

LG, Sebastian

von Yalu X. (yalu) (Moderator)


Lesenswert?

Mit Fortran 2023, dessen Spezifikation im Oktober offiziell von der
ISO/IEC veröffentlicht werden soll

  https://wg5-fortran.org/f2023.html

werden sowieso alle anderen Programmiersprachen obsolet.

von Andreas H. (ahz)


Lesenswert?

Yalu X. schrieb:
> Mit Fortran 2023, dessen Spezifikation im Oktober offiziell von der
> ISO/IEC veröffentlicht werden soll
>
>   https://wg5-fortran.org/f2023.html
>
> werden sowieso alle anderen Programmiersprachen obsolet.

Sie bauen aber schon praktisch Sachen ein, z.B (N2212.pdf):

2.4 US 22. Conditional expressions and arguments
Conditional expressions, expressions whose value is one of several 
alternatives, are added. A simple example is value = ( a>0.0 ? a : 0.0)

/regards

von Norbert (der_norbert)


Lesenswert?

Andreas H. schrieb:
> 2.4 US 22. Conditional expressions and arguments
> Conditional expressions, expressions whose value is one of several
> alternatives, are added. A simple example is value = ( a>0.0 ? a : 0.0)

Ein guter C-Programmierer kann in jeder Sprache guten C-Code schreiben!

von Andreas H. (ahz)


Lesenswert?

Norbert schrieb:
> Ein guter C-Programmierer kann in jeder Sprache guten C-Code schreiben!

Schon. Aber ein conditional assignment gibt es ja auch nicht in jeder 
Programmiersprache (hint: die LHS ist fix, im Gegensatz zu 
If/then/else).

Ich finde es ja nur lustig, dass da wirklich immer noch weiter 
Standardisiert wird. Anscheinend ist die Sprache doch noch nicht so ganz 
auf der Rampe.

/regards

: Bearbeitet durch User
von Rene K. (xdraconix)


Lesenswert?

Tilo R. schrieb:
> Jünglinge
> zeitlebens noch keine Prilblume gesehen haben.

Gibt es seit geraumer Zeit wieder auf den Prilflaschen... so zur Info. 
;-)

von Yalu X. (yalu) (Moderator)


Lesenswert?

Vanye R. schrieb:
> Wenn Programme nur so gross sein
> duerfen wie ein Programmierer Lochkarten in einen Schuhkarton bekommt,
> so manches ueble Machwerk der Zunft wuerde uns erspart werden.

Führende Schuhhersteller haben bereits angekündigt, ihr Sortiment nach
oben abzurunden (die Rede ist von Schuhgröße 3300), um die IT-Industrie
mit ausreichend großen Schuhkartons zur Aufbewahrung der über 22m langen
ISO/IEC-1539:2023-konformen Lochkarten versorgen zu können.

Zitat aus

ISO/IEC JTC1/SC22/WG5 N2212 – The new features of Fortran 2023:

"In free source form, the limit on line length is raised to ten thousand
characters […]"

von Uwe B. (boerge) Benutzerseite


Lesenswert?

...ich oute mich gern mal als oldschool, retro, ....was auch immer, 
...aber immerhin seit >35 Jahren im "Software-Geschäft"... und gerne 
auch den nun folgenden S**tstorm über mich (ich bin alt genug, um über 
den Dingen zu stehen ;-)).

Vanye R. schrieb:
> enthaelt den ersten Teil eines neuen
> FORTRAN-Kurs!

Sebastian W. schrieb:
> COBOL war schlimmer.

...etc. ....

Es ist ja schön, dass ihr euch über diese Dinge lustig macht, aber:

Zwar egal, aber wahrscheinlich ward ihr noch nicht mal geboren, als 
diese Programmiersprachen erfunden und (erstmals) im breiten Rahmen 
verwendet wurden... --> das waren alles Idioten? --> hmm, ziemlich 
respektlos, oder?

Nebenbei, damals, wie auch heute, hat jede Programmiersprache ihre 
Spezialisierung ("einen Nagel schlage ich nicht mit einem Hammer aus dem 
Holz, sondern verwende, sinnvollerweise, eine Zange").

Aber um mal in die "Neuzeit" anzukommen: was schätzt ihr eigentlich, wie 
viel dieser damals in Cobol oder Fortran, was auch immer, geschrieben 
Applikationen heute noch "rumlaufen"? Warum sollte man "99,99%ig" 
fehlerfrei, und im Fall von Fortran, performant laufende Software neu 
schreiben? Gleiches gilt auch teilweise für spezielle, vermeindlich 
veraltete Hardwareplattformen....

Ich muss ja immer über diese, hier jährlich laufenden Threads, "Was 
verdient ein XXX 20xx" schmunzeln. Noch viel lustiger sind dann die 
"meiner ist viel länger und du bist ja so doof"-Kommentare!

...schon mal darüber nachgedacht, wie viel ein Software-Entwickler wert 
ist, der Fortran oder Cobol zu mindesten lesen kann?

Grüße Uwe

PS.: Python hat diese Geschichte mit der "Code-Einrückung" als 
"Block-Kennzeichnung" nicht neu erfunden ;-)

: Bearbeitet durch User
von Andreas H. (ahz)


Lesenswert?

Uwe B. schrieb:
> ... und gerne
> auch den nun folgenden S**tstorm über mich

Sry, mit Shitstorm kann ich leider nicht aushelfen :)

Aber man sollte dazu noch erwähnen, das Cobol 2023 immer noch eine der 
am meisten eingesetzten Programmiersprachen ist.

Banken, Versicherungrn, Behörden. International wird da seit ewigen 
Zeiten Cobol benutzt. Und die wollen natürlich das Risk nicht eingehen 
die SW neu zu schreiben.
Insbesondere ist ein Cobolprog ja meist als Job im Mainframe 
eingebettet. Das ist etwas anderes als 10 Zeilen Python- oder Kakaducode 
.P

Letztes, mir aufgefallenes, Beispiel dazu war der Umzug der NYSE EDV vom 
Mainframe auf Workstations. Die NYSE hatte erst zugestimmt als 
garantiert war, dass die (Cobol-)SW nahtlos weiterbenutzt werden kann.

Irgendwie kneifen die SW-Helden immer wenn sie die Haftungsklausel 
lesen^^

/regards

von Uwe B. (boerge) Benutzerseite


Lesenswert?

Andreas H. schrieb:
> /regards

thanks ;-)

von Vanye R. (vanye_rijan)


Lesenswert?

> Es ist ja schön, dass ihr euch über diese Dinge lustig macht, aber:

Ich mach mich keineswegs ueber die Sprache lustig. Ich kenne ihre
Geschichte, mir ist klar das manches Produktiv eingesetzt wird
weil es lange da und fehlerfrei ist, und mir ist auch klar das sie
unter bestimmten Gruenden auch heute noch fuer neues Programme
sinnvoll sein kann. Letzeres z.B dann wenn du krasser Physiker mit
komplexen Projekten im Kopf bist die du nur mal schnell rechnen
willst ohne dich gleich mit dem erlernen einer modernen Sprache
zu beschaeftigen.

Es wundert mich nur das man ausgerechnet in der c't sowas fuer 
Einsteiger
propagiert. Aber die c't hat uns auch schonmal erzaehlt das die Zukunft 
des Programmierens in Smalltalk und Prolog zu finden sein wird. :)

Vanye

von Uwe B. (boerge) Benutzerseite


Lesenswert?

Vanye R. schrieb:
> Es wundert mich nur das man ausgerechnet in der c't sowas fuer
> Einsteiger propagiert.

...du hast mich "angefixt", ich werde wohl morgen mal zu meinem 
Zeitungsladen pilgern...

Grüße Uwe

von Sebastian W. (wangnick)


Lesenswert?

Uwe B. schrieb:
> Sebastian W. schrieb:
>> COBOL war schlimmer.
> aber immerhin seit >35 Jahren im "Software-Geschäft"

Hallo Youngster! Ich wurde vor 42 Jahren kurzzeitig gezwungen, COBOL zu 
programmieren. Insofern ist meine Respektlosigkeit Altersweisheit (oder 
-starrsinn :).

LG, Sebastian

von Stefan F. (Gast)


Lesenswert?

Norbert schrieb:
> Einfach schauen wo im Ort ein altes Haus mit der Birne abgerissen wird.
> Meistens bleibt eine Wand bis zum Schluss stehen und will einfach nicht
> umfallen.
> Das war die Küche, Fliesenwand, Prilblumen…

Die Bauarbeiter lassen die Wand möglichst lange stehen, weil sie die 
Pril Blumen so toll finden.

Ich kenne die noch aus meiner frühen Kindheit in Omas Küche.

von Uwe B. (boerge) Benutzerseite


Lesenswert?

Sebastian W. schrieb:
> Hallo Youngster! Ich wurde vor 42 Jahren
...mag sein, mir fehlen nur <= 7 Jahre ;-)...

Sebastian W. schrieb:
> ... kurzzeitig ..., COBOL zu programmieren.

...du hättest länger dabei bleiben sollen... ;-)

Grüße Uwe

von Uwe B. (boerge) Benutzerseite


Lesenswert?

Stefan F. schrieb:
> Die Bauarbeiter lassen die Wand möglichst lange stehen, weil sie die
> Pril Blumen so toll finden.

...der passt ganz gut zu meinem ersten Post!

Grüße & Danke Uwe

von Vanye R. (vanye_rijan)


Lesenswert?

> ...du hast mich "angefixt", ich werde wohl morgen mal zu meinem
> Zeitungsladen pilgern...

Naja, wenn du dann doch nicht zum Fortranprogrammierer wirst,
es ist immerhin noch ein interessanter Artikel zu Fehlerkorrektur
bei Flashspeichern drin. :)

Vanye

von Uwe B. (boerge) Benutzerseite


Lesenswert?

Vanye R. schrieb:
> wenn du dann doch nicht zum Fortranprogrammierer wirst

keine Sorge, ich kann Fortran lesen und schreiben ;-)

Uwe

von Roland F. (rhf)


Lesenswert?

Hallo,
Uwe B. schrieb:
> PS.: Python hat diese Geschichte mit der "Code-Einrückung" als
> "Block-Kennzeichnung" nicht neu erfunden ;-)

Nur wäre es schön wenn manche Erfindungen nur einmal erfunden würden.

rhf

von Sebastian W. (wangnick)


Lesenswert?

Uwe B. schrieb:
> ...du hättest länger dabei bleiben sollen... ;-)

Na ja, als Programmierer fängt man sich über die Jahre ja die Denkmuster 
einer Sprache etwas ein, und COBOL ist nicht sonderlich reflektiert :)

LG, Sebastian

von Uwe B. (boerge) Benutzerseite


Lesenswert?

Roland F. schrieb:
> Nur wäre es schön wenn manche Erfindungen nur einmal erfunden würden.

Warum, ist doch eine coole und logische Geschichte/Erfindung!

Uwe

von Uwe B. (boerge) Benutzerseite


Lesenswert?

Sebastian W. schrieb:
> COBOL ist nicht sonderlich reflektiert

...aber doch logisch konsequent, finde ich zu mindestens! Kommt immer 
darauf an, worauf man sich einlässt!

Uwe

: Bearbeitet durch User
von Roland F. (rhf)


Lesenswert?

Hallo,
Uwe B. schrieb:
> Warum, ist doch eine coole und logische Geschichte/Erfindung!

Da bin ich ganz anderer Meinung, für mich ist es eine der schlechtesten 
Eigenschaften einer Programmiersprache, das die Quelltextstruktur 
Einfluss auf die Semantik hat. Aber das ist eine andere Geschichte.

Noch was zum ursprünglichen Thema:

https://de.wikipedia.org/wiki/Manfred_Mohr_(K%C3%BCnstler)#Arbeitsweise

Schon interessant wofür uralte Programmiersprachen genutzt werden.

rhf

von Uwe B. (boerge) Benutzerseite


Lesenswert?

Moin,

Roland F. schrieb:
> Da bin ich ganz anderer Meinung, für mich ist es eine der schlechtesten
> Eigenschaften einer Programmiersprache, das die Quelltextstruktur
> Einfluss auf die Semantik hat.

...sicherlich Geschmackssache, ...irgendwo, u.U. versteckte 
geschweifte/eckige/"was-auch-immer" Klammern, die man im Quelltext 
suchen muss, sind auch nicht besonders optimal!

Uwe

von Günther K. (avr-guenther)


Lesenswert?

Hi,

ihr habt RPG vergessen.

Diese Programmiersprache wurde von der IBM bevorzugt, war streng 
Lochkarten orientiert und überall wo noch eine IBM /34 - /36 - /38 
rumsteht bzw. arbeitet da ist auch moch RPG am werkeln.

Allerdings hatte man(n) bei der IBM schon früh erkannt (so Ende der 
70ger) glaube ich dass es Lieferprobleme mit Lochkarten geben könnte. 
Deshalb hatte man einen Programmiereditor entworfen - ich glaube der 
hiess WSU - der Lochkarten ähnliche Eingaben gestatte.

Der Sinn von RPG? RPG war eine prozedurale Sprache die Datenbank 
Funktionen - ähnlich wie später dBase - inne hatte.

Das war natürlich für Verwaltungs-/Kaufmännische Anwenungen optimal.

Ciao Günther

von Christian M. (christian_m280)


Lesenswert?

Uwe B. schrieb:
> Moin,
> Roland F. schrieb:
>> Da bin ich ganz anderer Meinung, für mich ist es eine der schlechtesten
>> Eigenschaften einer Programmiersprache, das die Quelltextstruktur
>> Einfluss auf die Semantik hat.
>
> ...sicherlich Geschmackssache, ...irgendwo, u.U. versteckte
> geschweifte/eckige/"was-auch-immer" Klammern, die man im Quelltext
> suchen muss, sind auch nicht besonders optimal!

In beiden Fällen ist der Code nur mit Syntax-highlighted Editor lesbar, 
der den Anfang bzw. das Ende des Blocks markiert.
Ohne jemals Python programmiert zu haben könnte ich mir vorstellen, dass 
genau diese Eigenschaft den Programmierer dazu zwingt sauberen Code zu 
schreiben. Aber eben nur im entsprechenden Editor.

Gruss Chregu

von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

Nachdem solche neuen Funktionen letztendlich in 
Maschinensprachenbefehlen realisiert werden müssen und Fortran auch auf 
neuen Prozessoren mit immer wieder neuen Architekturen laufen soll, hat 
damit der Maschinensprachenlevel und damit verbundene 
Programmiersprachen zwangsläufig immer eine Zukunft.

von Re D. (Gast)


Lesenswert?

Roland F. schrieb:
> Da bin ich ganz anderer Meinung, für mich ist es eine der schlechtesten
> Eigenschaften einer Programmiersprache

Deine Meinung kannst du haben. Aber wie würde ein fremder, objektiver 
dritter das wohl bewerten? Unter Annahme der Verwendung einer modernen 
IDE würde er wohl sagen, ist egal. Unter Annahme eines Texteitors und 
eines unerfahrenen Programierers wird python den besser lesbaren Code 
liefern. Bei Annahme eines geübten Programierers gibt es keinen 
Unterschied außer ein paar unnütze klammern.

Der große Vorteil von Python ist doch, dass es, dank der vielen 
eingebauten Funktionen, für den Nutzer das beste Aufwand/Nutzen 
Verhältnis bietet. Eine csv Datei einlesen? Braucht 6 Zeilen. Aus einem 
String ein Zeichen entfernen? Eine Zeile. f-strings lassen sich fast wie 
Fließtext schreiben, nicht so Cryptorechtes Zeug, wie in C

Norbert schrieb:
> Ein guter C-Programmierer kann in jeder Sprache guten C-Code schreiben!

Ja, das sieht man hier öfters. Da sieht dann der Python-Code wie C-Code 
ohne Klammern aus.

von Stefan F. (Gast)


Lesenswert?

Dieter D. schrieb:
> hat damit der Maschinensprachenlevel und damit verbundene
> Programmiersprachen zwangsläufig immer eine Zukunft.

Das sehe ich auch so, für Betriebssysteme. Assembler und C (oder 
ähnlich) wird es wohl immer geben.

Bei Anwendungsprogrammen kann ich mir allerdings inzwischen gut 
vorstellen, dass die höheren Programmiersprachen zunehmend durch 
Scriptsprachen ersetzt werden (vor 20 Jahren hätte ich das noch nicht 
geschrieben). Denn Scriptsprachen sind leichter zu erlernen, man kommt 
damit schneller zum Ziel und sie sind Plattform-unabhängig. Den Nachteil 
der langsameren Performance gleicht die inzwischen reichlich schnellere 
HW aus. Für die Hot Spots haben wir ja immer Module in Assembler oder C 
oder ähnlich.

von Vanye R. (vanye_rijan)


Lesenswert?

> Nur wäre es schön wenn manche Erfindungen nur einmal erfunden würden.

Das bringt mich auf eine interessante Frage.

In dem Fortranartikel geht die Autorin auch auf CSV Dateien ein und wie 
man sie mit Fortran erzeugt. So weit so gut und bekannt. Des weiteren 
spricht sie dort von TSV-Dateien und meint damit "tabulatorgetrennte 
Tabelle". Ist das was neues? Ist es bisher an mir vorbeigegangen? Wird 
das ernsthaft irgendwo verwendet? Unterscheidet man da bewusst zwischen 
Space und Tab?

Vanye

von Norbert (der_norbert)


Lesenswert?

Roland F. schrieb:
> Da bin ich ganz anderer Meinung, für mich ist es eine der schlechtesten
> Eigenschaften einer Programmiersprache, das die Quelltextstruktur
> Einfluss auf die Semantik hat.

Ich schäme mich nicht zuzugeben, das auch ich am Anfang so über Python 
dachte.
Dann allerdings, gut eine Minute später, hab' ich es dennoch mal 
probiert. Was soll ich sagen?

Es klappt!

Und auch mir ist es nicht nur einmal, sondern zweimal passiert, das ich 
die Einrückung vergurkt hatte.
Zur großen Erleichterung nutzte ich die mir bis dato völlig unbekannte 
Tastenkombination Ctrl-Z (oder war's ›ESC-u‹?).

Und nein, ich nehme gerne auch einen ganzen Sack voller 'normaler' 
Editoren (vi, kate, pluma, geany,…), nicht nur spezialisierte IDEs. Ich 
erinnere gerne (als abschreckendes Beispiel) den ›Nazi‹-Editor in 
mbp-Cobol. Der sagte einem schon was man denken und machen durfe.

Mittlerweile, nicht erst nach einer nunmehr sechsstelligen Anzahl LOC 
allein in dieser ›schrecklichen‹ Python-Programmiersprache, denke ich 
wie alle anderen auch gar nicht mehr darüber nach. Wozu auch? Bin 
wirklich alt genug, um mir nicht ständig und verzweifelt Probleme 
einzubilden wo keine sind.

von Peter (pittyj)


Lesenswert?

Günther K. schrieb:
> Der Sinn von RPG? RPG war eine prozedurale Sprache die Datenbank
> Funktionen - ähnlich wie später dBase - inne hatte.
>
> Das war natürlich für Verwaltungs-/Kaufmännische Anwenungen optimal.

Ich habe vor 40 Jahren mal in RPG programmieren dürfen. Es war schlimm.
Alle Variablen, Labels etc mussten auf exakt vorgegeben Spalten stehen.
Es gab keine Kontrollstrukturen, es war alles ein goto-Brei.
Zum Beenden des Programmes gab es kein exit() oder ähnliches, man musste
Seton LR sagen, dafür dass der letzte Datenrecord prozessiert wurde.

Da war ich froh, als ich auf Rechner mit Pascal und ähnlichem Wechseln 
konnte.

Das System hatte ein paar DB-Zugiffsmethoden, für Kaufmänner wohl ganz 
praktisch. Allesdings war auch die /36 Hardware eigentlich nur ein 
8-Bitter mit 64 K Addressraum.

Alles aus meinen Erinnerungen heraus.

von Jens B. (dasjens)


Lesenswert?

Uwe B. schrieb:
> Es ist ja schön, dass ihr euch über diese Dinge lustig macht, aber:
>
> Zwar egal, aber wahrscheinlich ward ihr noch nicht mal geboren, als
> diese Programmiersprachen erfunden und (erstmals) im breiten Rahmen
> verwendet wurden... --> das waren alles Idioten? --> hmm, ziemlich
> respektlos, oder?

Hat das irgendwer behauptet? Ich hab nichts davon lesen können.
Dieses rumgeheule heutzutage immer.

von Michael D. (nospam2000)


Lesenswert?

Andreas H. schrieb:
> Conditional expressions, expressions whose value is one of several
> alternatives, are added. A simple example is value = ( a>0.0 ? a : 0.0)

in einigen Firmen ist dieses Konstrukt mittlerweile verpönt bis verboten 
(z.B in Javascript https://rules.sonarsource.com/java/rspec-1774/) und 
die kommen jetzt und führen es ein...

  Michael

von Harald K. (kirnbichler)


Lesenswert?

Vanye R. schrieb:
> ... spricht sie dort von TSV-Dateien und meint damit "tabulatorgetrennte
> Tabelle".

"tab-separated values".

> Ist das was neues?

Nein.

> Ist es bisher an mir vorbeigegangen?

Wohl ja.

> Wird das ernsthaft irgendwo verwendet?

Schon. Ist halt einfach eine Alternative zu CSV, und im Gegensatz zu dem 
auch eindeutig ("Deutsches CSV" müsste eigentlich "SSV" heißen, weil das 
Trennzeichen kein Komma, sondern ein Semikolon ist. Dateiformate, die 
von der Lokalisation abhängen, sind irgendwie große Scheiße).

von P. S. (namnyef)


Lesenswert?

Ein Schriftsteller, der sich ständig damit beschäftigt welchen Stift er 
verwenden soll, ist ja auch kein guter Schriftsteller.

von Norbert (der_norbert)


Lesenswert?

Michael D. schrieb:
> in einigen Firmen ist dieses Konstrukt mittlerweile verpönt bis verboten
> (z.B in Javascript https://rules.sonarsource.com/java/rspec-1774/)

"its use can make code more difficult to read."

Und als abschreckendes Beispiel führen sie:
1
System.out.println(i > 10 ? "yes" : "no");
an?
Sagt das nun etwas über das Konstrukt, die Java Programmierer im 
Allgemeinen oder sonarlint im Speziellen aus? ;-)

von Yalu X. (yalu) (Moderator)


Lesenswert?

Michael D. schrieb:
> Andreas H. schrieb:
>> Conditional expressions, expressions whose value is one of several
>> alternatives, are added. A simple example is value = ( a>0.0 ? a : 0.0)
>
> in einigen Firmen ist dieses Konstrukt mittlerweile verpönt bis verboten
> (z.B in Javascript https://rules.sonarsource.com/java/rspec-1774/) und
> die kommen jetzt und führen es ein...

Manche Leute brauchen eben etwas länger, um die Sinnhaftigkeit dieses
Konstrukts zu erkennen.

Aber die Zeiten bessern sich: Während in Fortran bis zur offiziellen
Einführung der Conditional Expressions 66 Jahre vergangen sind, waren es
in Python nur 14 Jahre :)

Norbert schrieb:
> Und als abschreckendes Beispiel führen sie:
>
> System.out.println(i > 10 ? "yes" : "no");
>
> an?
> Sagt das nun etwas über das Konstrukt, die Java Programmierer im
> Allgemeinen oder sonarlint im Speziellen aus? ;-)

Ich würde sagen, die Fa. Sonar hat gedankenlos möglichst viele Regeln in
ihren SonarLint gepackt, um diesen als hochwertiges Produkt erscheinen
zu lassen. Die Regel

"The ternary operator should not be used"

ist aber wohl eher als Empfehlung gedacht, denn zum einen steht da ein
"should" und kein "shall", zum anderen gibt es noch die Regel

"Ternary operators should not be nested"

die ja obsolet wäre, wenn man die erste Regel ernst nehmen würde.

von Roland F. (rhf)


Lesenswert?

Hallo,
Re D. schrieb:
> Deine Meinung kannst du haben.

Danke.

> Bei Annahme eines geübten Programierers gibt es keinen
> Unterschied außer ein paar unnütze klammern.

Dafür gibt es dann einige unnütze Doppelpunkte und "def"s. Aber lassen 
wir das.

> Eine csv Datei einlesen? Braucht 6 Zeilen. Aus einem
> String ein Zeichen entfernen? Eine Zeile. f-strings
> lassen sich fast wie Fließtext schreiben...

Sinnloser Vergleich, da beide Sprachen für völlig andere 
Anwendungsbereiche gedacht sind (C könnte das aber mit der 
entsprechenden Bibliothek genau so).

> ...nicht so Cryptorechtes Zeug, wie in C

Niemand zwingt einen kryptischen C-Code zu produzieren.

rhf

von Roland F. (rhf)


Lesenswert?

Hallo,
Stefan F. schrieb:
> Denn Scriptsprachen sind leichter zu erlernen, man kommt
> damit schneller zum Ziel und sie sind Plattform-unabhängig.

Verstehe ich nicht. Das könnte man doch genau so gut auch mit Nicht- 
Skriptsprachen realisieren.

> Den Nachteil der langsameren Performance gleicht die inzwischen
> reichlich schnellere HW aus.

Ich habe selbst bei Verwendung von "normalen" Sprachen schon seit Jahren 
oft nicht mehr den Eindruck, das immer schnellere Hardware zu 
schnelleren Programmen führt.

> Für die Hot Spots haben wir ja immer Module in Assembler oder C
> oder ähnlich.

Ich fände es besser wenn man nur eine Sprache für ein Problem nutzen 
müsste als noch eine zweite wenn es mal klemmt. Das könnte man ja 
vielleicht mit Compilern erreichen, die die permanente Interpretation 
von Skriptcode überflüssig machen (bei Python gibt es so was wohl mit 
CPython schon).

rhf

P.S.

von Re D. (Gast)


Lesenswert?

Roland F. schrieb:
> Sinnloser Vergleich, da beide Sprachen für völlig andere
> Anwendungsbereiche gedacht sind (C könnte das aber mit der
> entsprechenden Bibliothek genau so).
Warum so agro?

Na dann kann man es gleich mit dem Vergleich lassen. Jeder 
Programmiersprache ist für ihren Anwendungsbereich am besten. Das C 
jetzt nicht für PC programmieren ist, ist mir zwar neu, aber dann ist es 
so. Und in Python braucht man gerade keine Bibiothek 3. Für die CSV 
Datei, weil es zum Standardpaket gehört. Aber macht auch keinen 
Unterschied.

von Stephan S. (uxdx)


Lesenswert?

Rust nicht vergessen. Ist angeblich speichersicher (Überläufe etc).
Mal sehen, wie lange sich das hält (gibt es ab etwa 2015 ?)

von Thomas W. (Gast)


Lesenswert?

Yalu X. schrieb:

> Manche Leute brauchen eben etwas länger, um die Sinnhaftigkeit dieses
> Konstrukts zu erkennen.
>
> Aber die Zeiten bessern sich: Während in Fortran bis zur offiziellen
> Einführung der Conditional Expressions 66 Jahre vergangen sind, waren es
> in Python nur 14 Jahre :)

Ich erinnere mich (mit Horror) an Computed GOTO 
(https://www.ibm.com/docs/en/openxl-fortran-aix/17.1.0?topic=attributes-go-computed).

Wenn Du dann fremden Code analysieren sollst war das schon eine richtige 
Herausforderung.

Gruesse


Th.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Thomas W. schrieb:
> Ich erinnere mich (mit Horror) an Computed GOTO

Das war halt die Mehrfachverzweigung in frühen FORTRAN-Versionen (als
der Name noch in Großbuchstaben geschrieben wurde). In FORTRAN 77 wurde
zwar eine strukturierte IF-Verzweigung einführt, die strukturierte
Mehrfachverzweigung in Form von SELECT-CASE kam aber erst mit Fortran
90.

Natürlich konnte man auch mit GOTO und Computed GOTO strukturiert
programmieren, das erforderte aber etwas Disziplin und wurde damals nur
von wenigen als sinnvoll angesehen. Alle anderen kochten lieber
italienische Nudelgerichte :)

: Bearbeitet durch Moderator
von Roland F. (rhf)


Lesenswert?

Hallo,
Re D. schrieb:
> Das C jetzt nicht für PC programmieren ist, ist mir zwar neu...

Mir auch.

> Und in Python braucht man gerade keine Bibiothek 3. Für die CSV
> Datei, weil es zum Standardpaket gehört.

Komischerweise gehören mathematische Funktionen (die ich für wichtiger 
halte als Funktionen zur Bearbeitung von CSV-Dateien) nicht zum 
Standardpaket und finden sich in einer Bibliothek wieder.

Im übrigen sehe ich keinen Unterschied darin ob die Sprache das jetzt 
direkt unterstützt oder per Bibliothek zu Verfügung steht.

> Aber macht auch keinen Unterschied.

Genau.

rhf

von Christoph M. (mchris)


Lesenswert?

>Im übrigen sehe ich keinen Unterschied darin ob die Sprache das jetzt
>direkt unterstützt oder per Bibliothek zu Verfügung steht.

>> Aber macht auch keinen Unterschied.

Naja .. die Versionen der Bibliotheken ändern sich schneller als die 
Sprachversion.
Bei Python gibt es schon exorbitant viele Versionen und der Sprung von 
2.7 auf 3 war besonders extrem.
Die Bibliotheken können sich noch schneller ändern.

von Re D. (Gast)


Lesenswert?

Roland F. schrieb:
> nicht zum Standardpaket und finden sich in einer Bibliothek wieder

Welche Funktion hätte den C zu bieten, die das Modul math nicht hat? Bin 
gespannt.

Roland F. schrieb:
> Im übrigen sehe ich keinen Unterschied darin ob die Sprache das jetzt
> direkt unterstützt oder per Bibliothek zu Verfügung steht.

Doch, das macht einen Unterschied. Oder bestellst du bei Amazon und 
wickelt den Transport selber ab, weil es keinen Unterschied macht, ob es 
Amazon für dich macht oder du selbst?

von Roland F. (rhf)


Lesenswert?

Hallo,
Re D. schrieb:
> Welche Funktion hätte den C zu bieten, die das Modul math nicht hat?

Ich verstehe die Frage in diesem Zusammenhang nicht, was meinst du 
genau?

> Oder bestellst du bei Amazon und wickelt den Transport selber ab, weil
> es keinen Unterschied macht, ob es Amazon für dich macht oder du selbst?

Auch hier kann deinem Vergleich nicht folgen, egal.

Im übrigen gehört zu jedem mir bekannten C-Compiler (1) die 
C-Standardbibliothek. Man könnte also den Standpunkt vertreten das die 
C-Standardbibliothek Bestandteil der Sprache ist (faktisch ist sie das 
auch). Und die Funktionen der Bibliothek sind mittels eines einzigen 
"#include" problemlos nutzbar. Das ist nicht wirklich weit von in die 
Sprache eingebauten Funktionen weg.

rhf

(1) Wer Gegenbeispiele kennt, bitte melden.

von Re D. (Gast)


Lesenswert?

Roland F. schrieb:
> Komischerweise gehören mathematische Funktionen (die ich für wichtiger
> halte als Funktionen zur Bearbeitung von CSV-Dateien) nicht zum
> Standardpaket und finden sich in einer Bibliothek wieder.

Roland F. schrieb:
>> Welche Funktion hätte den C zu bieten, die das Modul math nicht hat?
>
> Ich verstehe die Frage in diesem Zusammenhang nicht, was meinst du
> genau?

Du stellst Behauptungen auf, aber kannst kein Beispiel bringen.
Vielleicht reden wir auch an einander vorbei? Python ist ein Interpreter 
und bringt viele Module mit, z.b. re oder eben csv. Csv war auch nur ein 
Beispiel,da muss man jetzt nicht 3 Stunden drauf rumreiten. Fakt ist, 
Python bringt viel mehr Funktionalität mit und es gibt sehr gute Module 
dritter, die als Open Source mit hervorragender Dokumentation angeboten 
werden.

von DSGV-Violator (Gast)


Lesenswert?

Paradox: Auch wenn die benutzte Hardware keine Zukunft hat, die 
darauf/dafür entwickelte Software hat sie.

Woraus folgt: das man immer HW-Ingenieure für die stete Neu-Erfindung 
der Hardware braucht, während der Bedarf an Softwerkern dank 
Wiederverwendbarkeit von Source-Code resp Konzepten sinkt.

von Abdul K. (ehydra) Benutzerseite


Lesenswert?

Die Stellenanzeigen sprechen schon seit Jahren da aber eine andere 
Sprache. Auch was Gehälter angeht.

von Mann Fred (Gast)


Lesenswert?

Vanye R. schrieb:
> enthaelt den ersten Teil eines neuen
> FORTRAN-Kurs!

40 Jahre zu spät. Fortran hatten wir in der Ausbildung. Später nie 
wieder verwendet. Welcher Kurz kommt als Nächstes, ADA?

von Daniel F. (df311)


Lesenswert?

Harald K. schrieb:
> "Deutsches CSV" müsste eigentlich "SSV" heißen, weil das
> Trennzeichen kein Komma, sondern ein Semikolon ist.

ich musste zum Glück schon lange nicht mehr mit Excel kämpfen, und hatte 
auch nie ein englisches/sonstige Sprachversion in der Hand.

Bist du dir sicher, dass das nicht ein "feature" dieser (hier beliebige 
Beschimpfungen, Verunglimpfungen, Beleidigungen, ... einsetzen) Software 
ist?
Weil z.B. Libreoffice weiß, dass das "C" in "CSV" für "Comma" steht, 
nicht für irgendwas anderes...

Harald K. schrieb:
> Dateiformate, die von der Lokalisation abhängen, sind irgendwie große Scheiße

ich finde noch schlimmer sind die übersetzten Funktionen in Excel

Manni T. schrieb:
> Welcher Kurz kommt als Nächstes, ADA?

unser Spasti-Basti Sebastian Kurz ;-)
na, ernsthaft(er) - ich habe mir ADA mal aus Interesse kurz angeschaut. 
Schaut so ähnlich aus wie VHDL

: Bearbeitet durch User
von Stefan F. (Gast)


Lesenswert?

DSGV-Violator schrieb:
> während der Bedarf an Softwerkern dank Wiederverwendbarkeit von
> Source-Code resp Konzepten sinkt.

Nein. Die Software ist nur deswegen so langlebig, weil sie weiter 
gepflegt wird. Und Software, die nicht (mehr) gepflegt wird, muss durch 
neue ersetzt werden. Auch diese fällt nicht zufällig im passendem Moment 
vom Himmel.

Bibliotheken und Frameworks beschleunigen die Entwicklung komplexer 
Software. Die Arbeit wird dadurch aber nicht einfacher, weil man sich 
nun mit viel breit gefächerten Fachgebieten und den Dokus der 
Bibliotheken auseinandersetzten muss. Nicht zu vergessen, die extrem 
zeitaufwändigen Fälle, wo eine Bibliothek mal unerwartet nicht das tut, 
was sie soll.

"Kein Problem, natürlich können wir die Reports als als verschlüsselte 
Mail senden. Kostet auch nicht extra."

Wer vom Fach ist weiß, wie viele Fallstricke so ein Angebot enthält.

von Ein T. (ein_typ)


Lesenswert?

Uwe B. schrieb:
> Roland F. schrieb:
>> Da bin ich ganz anderer Meinung, für mich ist es eine der schlechtesten
>> Eigenschaften einer Programmiersprache, das die Quelltextstruktur
>> Einfluss auf die Semantik hat.
>
> ...sicherlich Geschmackssache, ...irgendwo,

Nicht wirklich. Guido van Rossum hat seine Designentscheidung einmal 
sehr eindrucksvoll erklärt, und wer diese Erklärung kennt, hat 
verstanden, daß Klammern nur redundanter, mithin überflüssiger Bullshit 
sind.

von Ein T. (ein_typ)


Lesenswert?

Roland F. schrieb:
> Re D. schrieb:
>> Und in Python braucht man gerade keine Bibiothek 3. Für die CSV
>> Datei, weil es zum Standardpaket gehört.
>
> Komischerweise gehören mathematische Funktionen (die ich für wichtiger
> halte als Funktionen zur Bearbeitung von CSV-Dateien) nicht zum
> Standardpaket und finden sich in einer Bibliothek wieder.

Selbstverständlich gehören die Bibliotheken "math" und "statistics" zu 
jeder Standardinstallation von Python.

Es ist sehr lustig, wenn Leute über Programmiersprachen schwadronieren, 
von denen sie offensichtlich nicht den leisesten Hauch einer Ahnung 
haben. Aber am Ende sagt das nur etwas über die Leute, und nicht über 
die Sprachen.

von Ein T. (ein_typ)


Lesenswert?

Christoph M. schrieb:
> Bei Python gibt es schon exorbitant viele Versionen

Stimmt, die Versionen 2 und 3. Also zwei.

> und der Sprung von
> 2.7 auf 3 war besonders extrem.

Ja, man muß jetzt Klammern bei print() benutzen. Unzumutbar extrem.

von Alexander S. (alesi)


Lesenswert?

Ein T. schrieb:
> wer diese Erklärung kennt, hat
> verstanden, daß Klammern nur redundanter, mithin überflüssiger Bullshit
> sind.

In Scheme und Lisp sind sie wesentlich.
https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/6515/sicp.zip/full-text/book/book-Z-H-10.html#%_sec_1.1

von Stefan F. (Gast)


Lesenswert?

Auf der Arbeit wurde ich daz gedrängt, in Go zu programmieren. Nach dem 
Durcharbeiten einiger Tutorials hatte ich davon abgeraten, aber ich kann 
das halt nicht alleine entscheiden.

2 Jahre später:
Letztendlich komme ich damit trotz nerviger Design-Mängel gut zurecht.

Ein guter Handwerken kommt auch mit anderen Werkzeugen zurecht.

von Roland F. (rhf)


Lesenswert?

Hallo,
Ein T. schrieb:
> Es ist sehr lustig, wenn Leute über Programmiersprachen schwadronieren,
> von denen sie offensichtlich nicht den leisesten Hauch einer Ahnung
> haben. Aber am Ende sagt das nur etwas über die Leute, und nicht über
> die Sprachen.

Und es ist noch lustiger wenn Leute anderen Leuten vorwerfen nicht den 
leisesten Hauch einer Ahnung zu haben, aber selbst nicht den 
Zusammenhang verstanden haben, in dem etwas gesagt wurde.

Niemand hat behauptet das die mathematischen Funktionen nicht 
Bestandteil einer Python-Installation sind. Konkret ging es darum das 
ich mich gewundert habe das die mathematischen Funktionen nicht 
Bestandteil der Kernsprache sind, wo doch, laut Re D., die Funktionen 
zur Bearbeitung von CSV-Dateien zum Kern gehören. So viel zum Thema 
schwadronieren.

rhf

von Roland F. (rhf)


Lesenswert?

Hallo,
Ein T. schrieb:
> Nicht wirklich. Guido van Rossum hat seine Designentscheidung einmal
> sehr eindrucksvoll erklärt, und wer diese Erklärung kennt, hat
> verstanden, daß Klammern nur redundanter, mithin überflüssiger Bullshit
> sind.

Ein T. schrieb:
> Ja, man muß jetzt Klammern bei print() benutzen. Unzumutbar extrem.

Na ja, Klammern scheinen ja dann doch nicht ganz so "überflüssiger 
Bullshit" zu sein.

rhf

von Re D. (Gast)


Lesenswert?

Roland F. schrieb:
> die mathematischen Funktionen nicht Bestandteil der Kernsprache sind, wo
> doch, laut Re D., die Funktionen zur Bearbeitung von CSV-Dateien zum
> Kern gehören.

Auch das hat niemand behauptet. Für csv macht man import csv.
Aber sag doch jetzt mal, welche mathematische Funktion (ohne Import) dir 
fehlt!

von Roland F. (rhf)


Lesenswert?

Hallo,
Re D. schrieb:
> Auch das hat niemand behauptet. Für csv macht man import csv.

Re D. schrieb:
> Und in Python braucht man gerade keine Bibiothek 3. Für die CSV
> Datei, weil es zum Standardpaket gehört.

Was wird denn da importiert wenn es keine Bibliothek ist?

Re D. schrieb:
> Aber sag doch jetzt mal, welche mathematische Funktion (ohne Import) dir
> fehlt!

z.B. sin(), cos(),...

rhf

von Re D. (Gast)


Lesenswert?

Roland F. schrieb:
> Was wird denn da importiert wenn es keine Bibliothek ist?

Bibiothek dritter ist die klar oder? Es macht halt einen Unterschied, ob 
ich im Quellcode schreibe import math, oder ob ich mir erst aus 
fragwürdiger Quelle eine Bib laden und installieren muss und diese dann 
verwenden kann. Die Diskussion ist müßig mit dir.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Roland F. schrieb:
> Niemand hat behauptet das die mathematischen Funktionen nicht
> Bestandteil einer Python-Installation sind. Konkret ging es darum das
> ich mich gewundert habe das die mathematischen Funktionen nicht
> Bestandteil der Kernsprache sind, wo doch, laut Re D., die Funktionen
> zur Bearbeitung von CSV-Dateien zum Kern gehören. So viel zum Thema
> schwadronieren.

In Python kann man unterscheiden zwischen Funktionen, die

1. immer,

2. nach dem Import eines mitgelieferten Standardmoduls oder

3. nach dem Import eines zusätzlich installierten Moduls

verfügbar sind. Mathematische Funktion wie sin() und log() gehören der
Kategorie 2 an, die Funktionen des csv-Moduls ebenso.

Re D. schrieb:
> Eine csv Datei einlesen? Braucht 6 Zeilen.

Ich dachte ursprünglich¹, Re D. hätte das so gemeint, dass dafür nur
Funktionen der Kategorie 1 verwendet werden, denn bei Verwendung des
csv-Moduls wären dafür keine 6 Zeilen erforderlich.

Selbst ohne Import lässt sich das Einlesen einfacher CSV-Dateien (ohne
Sonderbehandlung bestimmter Zeichen) in nur einer Zeile realisieren.

Re D. schrieb:
> Aus einem String ein Zeichen entfernen? Eine Zeile. f-strings lassen
> sich fast wie Fließtext schreiben

Auch für die f-Strings muss nichts importiert werden.

──────────────
¹) Dieser meiner Interpretation hat Re D. leider (und zudem
   unnötigerweise ;-)) gerade widersprochen.

: Bearbeitet durch Moderator
von Benedikt L. (Firma: Dem Ben seine Leiche) (dembenseineleiche) Flattr this


Lesenswert?

FORTRAN und FORTH. Damit wird man zukünftig bestehen können!

Natürlich noch Arduinoi-C und der Witz wird rund!

von Ein T. (ein_typ)


Lesenswert?

Roland F. schrieb:
> Hallo,
> Ein T. schrieb:
>> Es ist sehr lustig, wenn Leute über Programmiersprachen schwadronieren,
>> von denen sie offensichtlich nicht den leisesten Hauch einer Ahnung
>> haben. Aber am Ende sagt das nur etwas über die Leute, und nicht über
>> die Sprachen.
>
> Und es ist noch lustiger wenn Leute anderen Leuten vorwerfen nicht den
> leisesten Hauch einer Ahnung zu haben, aber selbst nicht den
> Zusammenhang verstanden haben, in dem etwas gesagt wurde.

Das stimmt -- und es wäre sicherlich auch hier wieder einmal lustig, 
wenn ich nicht haargenau verstanden hätte, wovon Du schwadroniert hast. 
Zum Beispiel hast Du folgenden widersprüchlichen Unfug behauptet:

> Roland F. schrieb:
>> Komischerweise gehören mathematische Funktionen (die ich für wichtiger
>> halte als Funktionen zur Bearbeitung von CSV-Dateien) nicht zum
>> Standardpaket und finden sich in einer Bibliothek wieder.

Verschiedene Funktionen mit mathematischem Bezug (wie sum(), pow(), 
min(), max(), divmod()) sind Bestandteil des Moduls "builtins", also 
immer(!) in jeder laufenden Instanz des Python-Interpreters vorhanden. 
53 weitere mehr oder weniger mathematische Funktionen finden sich im 
Standardmodul "math", das ein Bestandteil der Standardbibliothek und 
damit ein Bestandteil jeder standardkonformen Python-Installation ist, 
weitere 18 Funktionen mit einem mathematischen Bezug finden sich im 
Standardmodul "statistics", die ebenso zum Umfang jeder 
standardkompatiblen Python-Installation gehört.

Die genannten Builtin-Funktionen sind sogar ohne Imports immer 
vorhanden, die Funktionen aus den Standardmodulen "math" und 
"statistics" nach einem Import der betreffenden Standardmodule. Die 
Unterschiede zwischen Python und C liegen also darin, daß man in C
1
#include <math>

schreibt und in Python
1
from math import *

schreiben muß, um einige mathematische Funktionen im globalen Namensraum 
benutzen zu können.

> Roland F. schrieb:
>> Im übrigen sehe ich keinen Unterschied darin ob die Sprache das jetzt
>> direkt unterstützt oder per Bibliothek zu Verfügung steht.

Gut, dann haben wir nach dieser Darstellung und dem, was ich zuvor 
gesagt habe, ja wohl eindeutig Klarheit, und diese Aussage von Dir:

> Roland F. schrieb:
>> Komischerweise gehören mathematische Funktionen (die ich für wichtiger
>> halte als Funktionen zur Bearbeitung von CSV-Dateien) nicht zum
>> Standardpaket

ist eindeutig Schwadronage, Unsinn, Quatsch, Bullshit, widerlegt, 
Gefasel eines Ahnungslosen oder etwas ähnliches in der Richtung. Du 
darfst Dir da gerne etwas aussuchen, solange es reflektiert, daß Du 
keine Ahnung hast, aber hier den Lauten gibst.

> Niemand hat behauptet das die mathematischen Funktionen nicht
> Bestandteil einer Python-Installation sind.

Aber ja doch, haargenau das hattest Du schwadroniert:

> Roland F. schrieb:
>> Komischerweise gehören mathematische Funktionen (die ich für wichtiger
>> halte als Funktionen zur Bearbeitung von CSV-Dateien) nicht zum
>> Standardpaket

> Konkret ging es darum das
> ich mich gewundert habe das die mathematischen Funktionen nicht
> Bestandteil der Kernsprache sind, wo doch, laut Re D., die Funktionen
> zur Bearbeitung von CSV-Dateien zum Kern gehören.

Komischer Unfug, denn Du hattest ja auch noch das hier geschrieben:

Roland F. schrieb:
> Im übrigen sehe ich keinen Unterschied darin ob die Sprache das jetzt
> direkt unterstützt oder per Bibliothek zu Verfügung steht.

Also wir können jetzt lange darüber diskutieren, was denn "Sprachkern" 
ist und was nicht, meiner Meinung nach sind Deine Definition nicht ganz 
korrekt und im engeren Sinn gehören die Standardbibliotheken nicht zum 
eigentlichen Kern einer Sprache, im Weiteren hingegen schon. Warum ich 
das unterscheide, liegt daran, daß es Installationsvarianten für 
spezielle Anwendungsfälle gibt, beispielsweise Micropython und den 
AVR-GCC, in deren Installationen einige Funktionen aus der 
Standardbibliothek fehlen.

Aber gut, lassen wir die diesbezügliche Erbsenzählerei und lassen uns 
auf Deine Aussage ein, derzufolge es keinen Unterschied macht, ob eine 
Sprache jetzt etwas fest eingebaut oder als Bibliothek mitbringt. In 
diesem Falle ist es nämlich so, daß Python mit Builtins und den 
Standardbibliotheken "math" und "statistics" zusammen also 76 mehr oder 
minder mathematische Funktionen in der Standardinstallation mitbringt. 
Zusätzlich hat Python allerdings auch noch eine Menge anderer 
Standardbibliotheken dabei, wie beispielsweise die von einem Vorredner 
genannte "csv" zum Verarbeiten von CSV-Dateien, "json" für 
(Überraschung!) JSON-Daten, und so weiter. Eine gute Übersicht bietet 
(wie so oft) die Dokumentation, die Du hier [1] finden kannst -- dort 
findest Du neben den Referenzen für die Sprache und die Bibliotheken 
übrigens auch ein sehr gutes Tutorial, damit Du auch ein bisschen was 
lernen, und in Zukunft vielleicht sogar etwas Sinnvolles und Korrektes 
beitragen kannst, statt Unfug zu schwadronieren. Viel Freude, Glück und 
Erfolg dabei!


[1] https://docs.python.org/

von Ein T. (ein_typ)


Lesenswert?

Roland F. schrieb:
> Ein T. schrieb:
>> Ja, man muß jetzt Klammern bei print() benutzen. Unzumutbar extrem.
>
> Na ja, Klammern scheinen ja dann doch nicht ganz so "überflüssiger
> Bullshit" zu sein.

Das stimmt. Wenn man das Schlüsselwort "print" entfernt und durch die 
Funktion "print()" ersetzt, dann sind Klammern sogar essentiell. Eine 
bahnbrechende Erkenntnis, bist Du da ganz alleine drauf gekommen? Ach 
stimmt ja, ich hatte das erwähnt... tut mir leid. ;-)

von Roland F. (rhf)


Lesenswert?

Hallo,
Re D. schrieb:
> Die Diskussion ist müßig mit dir.

dito.

rhf

von Roland F. (rhf)


Lesenswert?

Hallo,
Ein T. schrieb:
> ist eindeutig Schwadronage, Unsinn, Quatsch, Bullshit, widerlegt,
> Gefasel eines Ahnungslosen oder etwas ähnliches in der Richtung. Du
> darfst Dir da gerne etwas aussuchen, solange es reflektiert, daß Du
> keine Ahnung hast, aber hier den Lauten gibst.

Überheblicher Flegel.

rhf

: Bearbeitet durch User
von Re D. (Gast)


Lesenswert?

Roland F. schrieb:
> Hallo,
> Ein T. schrieb:
>> ist eindeutig Schwadronage, Unsinn, Quatsch, Bullshit, widerlegt,
>> Gefasel eines Ahnungslosen oder etwas ähnliches in der Richtung. Du
>> darfst Dir da gerne etwas aussuchen, solange es reflektiert, daß Du
>> keine Ahnung hast, aber hier den Lauten gibst.
>
> Überheblicher Flegel.
> rhf

Ein T. Hat es gut zusammengefasst. Deine Beleidigung, kannst du 
behalten. Immer 2x mehr wie du.

von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

Stefan F. schrieb:
> Dieter D. schrieb:
>> hat damit der Maschinensprachenlevel und damit verbundene
>> Programmiersprachen zwangsläufig immer eine Zukunft.
>
> Das sehe ich auch so, für Betriebssysteme. Assembler und C (oder
> ähnlich) wird es wohl immer geben.
>
> Bei Anwendungsprogrammen kann ich mir allerdings inzwischen gut
> vorstellen, dass die höheren Programmiersprachen zunehmend durch
> Scriptsprachen ersetzt werden

Das baut aufeinander auf. Es wird meistens die Programmiersprache & 
Ebene verwendet, mit der die Programmieraufgabe schneller gelöst werden 
kann. In Fortran sind viele umfangreiche Mathematikbibliotheken 
geschrieben. Diese werden auch heute noch in anderen Programmiersprachen 
angebunden.

von Jens K. (jensky)


Lesenswert?

Also ich habe letztens BASCOM von MCS in den Fingern gehabt. DAS hat 
Zukunft.

BASCOM ist gut!

: Wiederhergestellt durch Moderator
von Ein T. (ein_typ)


Lesenswert?

Roland F. schrieb:
> Hallo,
> Ein T. schrieb:
>> ist eindeutig Schwadronage, Unsinn, Quatsch, Bullshit, widerlegt,
>> Gefasel eines Ahnungslosen oder etwas ähnliches in der Richtung. Du
>> darfst Dir da gerne etwas aussuchen, solange es reflektiert, daß Du
>> keine Ahnung hast, aber hier den Lauten gibst.
>
> Überheblicher Flegel.

Tolles (*) "Argument"... Aber es ist nicht meine Schuld, daß Du nicht 
den leisesten Hauch einer Ahnung hast und hier trotzdem den Lauten 
machst.

(*) think "Tollkirsche", "Tollwut", oder "Tollhaus"

von Stefan F. (Gast)


Lesenswert?

Jens K. schrieb:
> Also ich habe letztens BASCOM von MCS in den Fingern gehabt. DAS hat
> Zukunft. BASCOM ist gut!

Leider auch ziemlich exotisch. Wenn du damit Probleme hast kann dir kaum 
jemand weiter helfen.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Jens K. schrieb:
> Also ich habe letztens BASCOM von MCS in den Fingern gehabt. DAS hat
> Zukunft.

Fortran (um das es in diesem Thread geht) und BASCOM sind zwei völlig
verschiedene Welten. Auf Plattformen, für die es Fortran gibt, gibt es
kein BASCOM und umgekehrt (mal abgesehen von experimentellen
Proof-of-Concept-Implementierungen).

Für eine gegebene Plattform fällt die Wahl zwischen Fortran und BASCOM
also sehr leicht ;-)

von Harald K. (kirnbichler)


Lesenswert?

Yalu X. schrieb:
> Auf Plattformen, für die es Fortran gibt, gibt es
> kein BASCOM und umgekehrt

Da bleibt also nur die logische Konsequenz, einen Fortran-Compiler für 
AVRs zu entwickeln.

Dürfte gar nicht so irrwitzig kompliziert sein, denn es gibt ein 
Fortran-Frontend für gcc:

https://gcc.gnu.org/fortran/

Also steht auch dem Arduinotran* kein wirkliches Hindernis im Wege.


*) Traniges in der bekannten minimalistischen IDE

von Yalu X. (yalu) (Moderator)


Lesenswert?

Harald K. schrieb:
> Yalu X. schrieb:
>> Auf Plattformen, für die es Fortran gibt, gibt es
>> kein BASCOM und umgekehrt
>
> Da bleibt also nur die logische Konsequenz, einen Fortran-Compiler für
> AVRs zu entwickeln.
>
> Dürfte gar nicht so irrwitzig kompliziert sein, denn es gibt ein
> Fortran-Frontend für gcc:
>
> https://gcc.gnu.org/fortran/

Es gibt mindestens eine (noch relativ unfertige) Implementierung für
Fortran auf AVRs:

  https://sourceforge.net/projects/avr-gfortran/

Dessen Entwicklung scheint Ende 2018 eingestellt worden zu sein, aber
vielleicht wird ja jemand durch den C't-Artikel von Fortran angefixt und
setzt die Entwicklung fort :)

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Wer mal GNU Octave aus den sourcen gebaut hat, wird wissen, dass man da 
doch die ein oder andere Library brauchen kann, die hauptsaechlich in 
Fortran geschrieben ist. Wer nur mit "sudo apt get gedoens" umgehen 
kann, ahnt das eher nicht.

Gruss
WK

von Oliver S. (oliverso)


Lesenswert?

Dergute W. schrieb:
> Wer nur mit "sudo apt get gedoens" umgehen
> kann, ahnt das eher nicht.

Wer vorhat, GNU Octave oder was mit linpack oder eispack auf einem AVR 
laufen zu lassen, muß das ahnen. Alle anderen eher nicht.

Oliver

: Bearbeitet durch User
von Re D. (Gast)


Lesenswert?

Oliver S. schrieb:
> Wer vorhat, GNU Octave oder was mit linpack oder eispack auf einem AVR
> laufen zu lassen, muß das ahnen. Alle anderen eher nicht.
>
> Oliver

Seit wann ist ein AVR ein PC?

von Fritz G. (fritz65)


Lesenswert?

Yalu X. schrieb:
> Harald K. schrieb:
>> Yalu X. schrieb:
>>> Auf Plattformen, für die es Fortran gibt, gibt es
>>> kein BASCOM und umgekehrt
>>
>> Da bleibt also nur die logische Konsequenz, einen Fortran-Compiler für
>> AVRs zu entwickeln.

> Es gibt mindestens eine (noch relativ unfertige) Implementierung für
> Fortran auf AVRs:
>
>   https://sourceforge.net/projects/avr-gfortran/
>
> Dessen Entwicklung scheint Ende 2018 eingestellt worden zu sein, aber
> vielleicht wird ja jemand durch den C't-Artikel von Fortran angefixt
Fortran für AVR mag eine nette Spielerei sein, sinnvoll ist das 
natürlich nicht. Die Domäne von Fortran ist nun mal das numerische 
„Zahlenfressen“ undda hatein AVR eher schlechte Karten.
Das Hauptproblem mit Fortran ist nicht die Sprache sondern die 
Programmierer, die oft auf dem Stand von F77 oder noch älter 
stehengeblieben sind. COMMON, arithmetic IF und numerische Labels sind 
solche Relikte aus der Computersteinzeit. Die neueren Varianten von 
Fortran (ab F90/95) kann man durchaus als moderne Programmiersprachen 
bezeichnen, u.a. können Vektoroperationen sehr kompakt und elegant 
codiert werden. Parallel- und Vektorrechner können den Fortran-Code 
meist auch gut optimieren. Auch  wenn heute viel mit Matlab, Octave o.ä. 
gemacht wird, ist Fortran für die professionelle Numerik immer noch eine 
gute Option.

von Ein T. (ein_typ)


Lesenswert?

Oliver S. schrieb:
> Dergute W. schrieb:
>> Wer nur mit "sudo apt get gedoens" umgehen kann,

... weiß vermutlich immerhin, daß es entweder "sudo apt-get install 
gedoens" oder "sudo apt install gedoens" heißen muß.

> Wer vorhat, GNU Octave oder was mit linpack oder eispack auf einem AVR
> laufen zu lassen, muß das ahnen. Alle anderen eher nicht.

Auch in numpy, scipy, statsmodels, scikit-learn, Pandas und Co. sind 
noch Libraries enthalten, die in Fortran entwickelt wurden.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.