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.
Dann nehme ich dich lieber das andere Magazin. Das veraltet eigentlich auch nicht wirklich 😂
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
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.
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.
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
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
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.
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
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!
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
Tilo R. schrieb: > Jünglinge > zeitlebens noch keine Prilblume gesehen haben. Gibt es seit geraumer Zeit wieder auf den Prilflaschen... so zur Info. ;-)
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 […]"
...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
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
> 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
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
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
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.
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
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
> ...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
Vanye R. schrieb: > wenn du dann doch nicht zum Fortranprogrammierer wirst keine Sorge, ich kann Fortran lesen und schreiben ;-) Uwe
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
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
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
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
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
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
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
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
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.
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.
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.
> 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
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.
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.
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.
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
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).
Ein Schriftsteller, der sich ständig damit beschäftigt welchen Stift er verwenden soll, ist ja auch kein guter Schriftsteller.
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? ;-)
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.
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
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.
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.
Rust nicht vergessen. Ist angeblich speichersicher (Überläufe etc). Mal sehen, wie lange sich das hält (gibt es ab etwa 2015 ?)
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.
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
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
>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.
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?
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.
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.
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.
Die Stellenanzeigen sprechen schon seit Jahren da aber eine andere Sprache. Auch was Gehälter angeht.
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?
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
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.
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.
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.
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.
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
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.
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
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
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!
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
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.
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
FORTRAN und FORTH. Damit wird man zukünftig bestehen können! Natürlich noch Arduinoi-C und der Witz wird rund!
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/
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. ;-)
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
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.
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.
Also ich habe letztens BASCOM von MCS in den Fingern gehabt. DAS hat Zukunft. BASCOM ist gut!
:
Wiederhergestellt durch Moderator
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"
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.
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 ;-)
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
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 :)
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
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
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?
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.