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!
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.
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.
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…
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)
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!
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 […]"
...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 ;-)).
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 ;-)
... 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^^
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. :)
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 :).
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.
...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. :)
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.
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!
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.
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.
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.
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
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.
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?
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.
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.
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.
... 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).
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 :)
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.
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.
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).
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.
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 :)
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 :)
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.
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.
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?
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.
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.
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.
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.
"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...
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.
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.
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.
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.
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.
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.
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!
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.
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
immer,
nach dem Import eines mitgelieferten Standardmoduls oder
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.
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.
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:
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.
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:
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:
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!
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. ;-)
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.
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.
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.
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"
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 ;-)
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 :)
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.
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.
