Kennt eigentlich jemand https://pascalabc.net/en/samples Offenbar gibt es neben dem Freepascal / Lazarus Projekt, doch immer wieder neue verbesserte Pascal Versionen Vom ABC Pascal hatte ich aber tatsächlich noch gar nicht gehört.
Was mir aber immer wieder auffällt, das in Russland Pascal offenbar aktiver genutzt wird als woanders. Und auf bei diesem Projekt sind wieder Russen beteiligt
Max M. schrieb: > Was mir aber immer wieder auffällt, das in Russland Pascal offenbar > aktiver genutzt wird als woanders. Die fliegen auch noch mit Rakten aus den 1970er Jahren ins Weltall. Das passt dazu! Echt russisch halt! ;-)
Falk B. schrieb: > Die fliegen auch noch mit Rakten aus den 1970er Jahren ins Weltall. > Das passt dazu! Echt russisch halt! ;-) Haben die sich sicher bei Perry Hoden abgekuckt. Der war ja recht erfolgreich damit.
Max M. schrieb: > Was mir aber immer wieder auffällt, das in Russland Pascal offenbar > aktiver genutzt wird als woanders. Was mir aber immer wieder auffällt ist dass ich Pascal absolut nicht vermisse seitdem ich angefangen habe C zu programmieren. Und das ist schon lang her.
Wastl schrieb: > Was mir aber immer wieder auffällt ist dass ich Pascal absolut > nicht vermisse seitdem ich angefangen habe C zu programmieren. Hm, ich programmiere seit über 20 Jahren mit C/C++ und vermisse Pascal dennoch, was der Grund ist, dass ich manche Desktopprogramme (und ein ewig währendes Konsolenprojekt das seit über 10 Jahren immer weiter wächst) tatsächlich immer wieder mal mit Lazarus schreibe. Bei größeren Projekten passiert mir (leider) immer wieder einmal, dass ich Dinge erledigen will, die in C normal sind und in Pascal nicht funktionieren. Allerdings gilt das auch umgekehrt: Kehre ich von Pascal in ein C Projekt zurück, versuche ich bspw. immer wieder einmal etwas zu machen, was in Pascal geht und in C nicht. Grundsätzlich fände ich schön, wenn es für C so etwas wie Lazarus in einer einzigen GUI Umgebung geben würde, das dann auch alle Abhängigkeiten mit in das ausführbare Binary statisch linkt (auch wenn so etwas bei manchen wohl verpönt ist). So muß ich den QT Creator und das Visual Studio verwenden. Lazarus finde ich intuitiver, jedoch ist eine IDE kein Vor- oder Nachteil einer Sprache. Schade, dass es so etwas wie Lazarus für Pascal/Delphi nicht auch für C/C++ gibt.
Ralph S. schrieb: > Grundsätzlich fände ich schön, wenn es für C so etwas wie Lazarus in > einer einzigen GUI Umgebung geben würde, das dann auch alle > Abhängigkeiten mit in das ausführbare Binary statisch linkt (auch wenn > so etwas bei manchen wohl verpönt ist). So muß ich den QT Creator und > das Visual Studio verwenden. Verstehe ich nicht... Warum willst du Qt&VS parallel verwenden? Ich habe schon wirklich ewig kein Qt Programm mehr statisch gelingt, aber damals war da einfach nur "CONFIG += static" im Project file einzutragen. Kann aber sein, dass du noch die statischen Libs nachinstallieren musst, damit das geht... Gerade der Qt creator ist eine vollintegrierte ide, die im Grunde alle Features von qt kann (also GUI design, übersetungen, android, bare metal MCU, JavaScript, ...). Sogar mehrere Compiler werden unterstützt (GCC und llvm... Wobei letzterer mMn besser verständliche warnings und Errors ausgibt...). 73
Ralph S. schrieb: > Lazarus finde ich intuitiver, jedoch ist eine IDE kein Vor- oder > Nachteil einer Sprache. Schade, dass es so etwas wie Lazarus für > Pascal/Delphi nicht auch für C/C++ gibt. Ich bin auch kein Freund von Pascal, aber Lazarus ist einfach unschlagbar. Da nehme ich die suboptimale Sprache gerne in Kauf.
Ralph S. schrieb: > das dann auch alle > Abhängigkeiten mit in das ausführbare Binary statisch linkt Was ist daran besonders? Das kann der von MS als "Visual Studio" vertriebene Compiler schon seit Jahrzehnten.
Hans W. schrieb: > Warum willst du Qt&VS parallel verwenden? von mir schlecht kommuniziert: Qt verwende ich privat, dienstlich muss ich VS !
Ralph S. schrieb: > Hans W. schrieb: >> Warum willst du Qt&VS parallel verwenden? > > von mir schlecht kommuniziert: Qt verwende ich privat, dienstlich muss > ich VS ! Ahhh, ok.
Falk B. schrieb: > Die fliegen auch noch mit Rakten aus den 1970er Jahren ins Weltall. > Das passt dazu! Echt russisch halt! ;-) Fun Fact: Dem Falk aus der SBZ seine Lieblingssprache, c, ist - Trommelwirbel - aus den 70ern. Und sprachlich FreePascal um Jahrzehnte hinterher.
Wastl schrieb: > Was mir aber immer wieder auffällt ist dass ich Pascal absolut > nicht vermisse seitdem ich angefangen habe C zu programmieren. > Und das ist schon lang her. Pascal nähert sich C bzw. C++ immer mehr an. Dieser Prozess hat vor 40 Jahren mit Turbo Pascal begonnen (Herrn Wirth dürften wohl die Haare zu Berge gestanden haben) und wurde mit Delphi, Free Pascal, mikroPascal und nun auch PascalABC fortgesetzt. PascalABC unterstützt nun bspw. auch blocklokale Variablen und Lambda-Ausdrücke. Vielleicht kommt irgendwann der Tag, an dem die schrecklichen BEGINs und ENDs durch schneller zu tippende und weniger aufdringliche geschweifte Klammern ersetzt werden ;-)
Du kannst es ja dem Freepascal Projekt vorschlagen. Viele solcher Änderungen sind in der IDE anwählbar, in welchem "Style" man schreiben möchte
Max M. schrieb: > Du kannst es ja dem Freepascal Projekt vorschlagen. > Viele solcher Änderungen sind in der IDE anwählbar, in welchem "Style" > man schreiben möchte Das ist gar nicht nötig. Man kann den Angleichungsprozess von Pascal nach C++ (und darüber hinaus) sogar dramatisch beschleunigen, ohne die wertvolle Zeit der Free-Pascal-Entwickler zu beanspruchen. Hier sind die erforderlichen Änderungen:
1 | alias fpc=clang++ |
Aber auch die neu hinzugefügten C++-Sprachfeatures sind noch nicht das Gelbe vom Ei und bedürfen deswegen noch einer kleinen Überarbeitung:
1 | alias clang++=rustc |
Schon besser. Wenn man aber schon am Optimieren der Sprache ist, kann man es auch gleich richtig machen:
1 | alias rustc="ghc -x hs" |
Zur Demonstration ein kleines Programm für den offiziellen FPC, das einfach den Datenstrom von stdin nach stdout kopiert: in2out1.pas:
1 | program CopyInputToOutput; |
2 | |
3 | var |
4 | c: char; |
5 | |
6 | begin |
7 | while not eof do |
8 | begin |
9 | read(c); |
10 | write(c) |
11 | end |
12 | end. |
O je, so viel Code für so eine einfache Aufgabe. Zudem scheint er zweimal zu beginnen und zweimal zu enden, was schon sehr komisch aussieht. Nun dasselbe Programm für den erweiterten FPC: in2out2.pas:
1 | main = interact id |
Kompiliert wird wie gewohnt mit
1 | fpc in2out2.pas |
Wo sind die BEGINs und ENDs geblieben, wo die verschachtelte Struktur des Originalcodes? Genau dahin muss sich Pascal in Zukunft entwickeln. Der FPC kann das dank der oben beschriebenen Änderungen schon heute ;-)
Früher™ bestand der Sinn einer Programmiersprache nicht nur darin, lauffähige Programme damit schreiben zu können, sondern auch, daß andere den Quelltext lesen und verstehen können. Mit der heutigen exponentiellen Proliferation von Programmiersprachen, Sprachversionen und Dialekten aber wird bald ein Zustand erreicht, in dem jeder Programmierer seine ihm eigene und für alle anderen weitestgehend unverständliche Programmiersprache einsetzt.
Yalu X. schrieb: > O je, so viel Code für so eine einfache Aufgabe. Zudem scheint er > zweimal zu beginnen und zweimal zu enden, was schon sehr komisch > aussieht. Da gibts dann Pascalversionen, bei denen es nach den While kein Begin gibt und das am Ende EndWhile heißt und so kann man das schön lesen. Wenn man dann noch fleißig mit Einrücken arbeitet, kapiert man das auch nach Jahrzehten noch 😉
Harald K. schrieb: > Mit der heutigen exponentiellen Proliferation von Programmiersprachen, > Sprachversionen und Dialekten aber wird bald ein Zustand erreicht, in > dem jeder Programmierer seine ihm eigene und für alle anderen > weitestgehend unverständliche Programmiersprache einsetzt. Damit nur der Programmierer sein Projekt versteht und damit immer wieder Geld verdienen kann, schon x-mal erlebt.
Uwe S. schrieb: > Damit nur der Programmierer sein Projekt versteht und damit immer wieder > Geld verdienen kann, schon x-mal erlebt. Früher™ haben Programmierer das mit normalen und allgemein verbreiteten Programmiersprachen hinbekommen, einfach durch die Qualität (oder "Qualität") ihres Codes. Dann wurden Programmierrichtlinien für Codedokumentation, -Qualität etc. eingeführt. Heute kann man durch geschickte Auswahl der Programmiersprache trotz Einhaltung sämtlicher Coderichtlinien genau das gleiche Ziel erreichen. Daß die Programmiersprache nur drei Programmierer nördlich des Mittelmeers und ein Einsiedler irgendwo in der Südsee verstehen, dafür kann der gewiefte Programmierer ja nun nichts, oder?
Harald K. schrieb: > dem jeder Programmierer seine ihm eigene und für alle anderen > weitestgehend unverständliche Programmiersprache einsetzt. Willkommen in Babylon!
Ich komme aus der zeit von PC-programmierung in DOS; Turbo Pascal 6.0 [mit Turbo Vision] Danach bin ich in embedded programmierung hinein gegangen (C). Vor 10 Jahren ein bisschen angefangen mit C# fuer PC programmierung. Da faellte mir direct auf das die object-orientierte structur von C# mir sehr bekannt vorkam. Die erklaerung : Anders Hejlsberg. Stand am basis von Turbo Pascal und C#. https://de.wikipedia.org/wiki/Anders_Hejlsberg Meiner meinung sind in C# viele erfahrungen von die Turbo Pascal zeit mitgenommen. Patrick aus die Niederlande
Harald K. schrieb: > Früher™ bestand der Sinn einer Programmiersprache nicht nur darin, > lauffähige Programme damit schreiben zu können, sondern auch, daß andere > den Quelltext lesen und verstehen können. Nö, spätestens mit der Erfindung von C (eigentlich schon bei dessen Vorgängern) wurde diese Idee aufgegeben. Immerhin gibt es aber für C zumindest einen Art Standard, später sogar einen echten Standard. Problem ist nur: inzwischen ist das auch schon wieder wesentlich mehr als nur einer. Wenn die Sprache wirklich gut gewesen wäre, hätte es bei einem bleiben können. War sie aber offensichtlich absolut nicht. Nunja, Pascal hat es meines Wissens nach niemals zu einem offiziellen Standard gebracht. War allerdings dafür von vornherein auf bessere *Menschen*-Lesbarkeit ausgelegt und auch ihre Weiterentwicklungen blieben diesem Grundkonzept überwiegend treu. Erst in jüngster Zeit drehen die Programmiersprachen-Designer auch hier völlig frei. Womit wir wohl beim Thema dieses Threads wären... Aber dieser Ausflug sei mir noch gegönnt: Die C-Weiterentwicklung C++ ist schon seit Jahrzehnten völlig in ähnlicher Weise völlig ausgetickt. Ich möchte angesichts der schieren Komplexität der Sprache behaupten, das es praktisch niemanden (also keinen Menschen) auf der ganzen Welt mehr gibt, der diese Sprache wirklich komplett beherrscht. Die was anderes behaupten, muß man einfach nur mal von der Möglichekeit abschneiden, jederzeit nachschauen zu können. Dann lernen auch die, dass diese Sprache unbrauchbar für Menschen ist.
Crazy H. schrieb: > Yalu X. schrieb: >> O je, so viel Code für so eine einfache Aufgabe. Zudem scheint er >> zweimal zu beginnen und zweimal zu enden, was schon sehr komisch >> aussieht. > Da gibts dann Pascalversionen, bei denen es nach den While kein Begin > gibt und das am Ende EndWhile heißt und so kann man das schön lesen. > Wenn man dann noch fleißig mit Einrücken arbeitet, kapiert man das auch > nach Jahrzehten noch 😉 Aber dann könnte man sich diesen ganzen End[...]-Krams doch gleich ersparen und nur mit Einrückungen arbeiten. :-)
Ein T. schrieb: > Aber dann könnte man sich diesen ganzen End[...]-Krams doch gleich > ersparen und nur mit Einrückungen arbeiten. :-) Es gibt Sprachen, die haben deine Idee einfach aufgegriffen :-)
Ein T. schrieb: > Aber dann könnte man sich diesen ganzen End[...]-Krams doch gleich > ersparen und nur mit Einrückungen arbeiten. :-) Uuuhhh, ich sehe einen Sturm seltsamer Färbung aufziehen… ;-)
Ein T. schrieb: > Aber dann könnte man sich diesen ganzen End[...]-Krams doch gleich > ersparen und nur mit Einrückungen arbeiten. :-) War das nicht Python?
Bernd S. schrieb: > Ein T. schrieb: >> Aber dann könnte man sich diesen ganzen End[...]-Krams doch gleich >> ersparen und nur mit Einrückungen arbeiten. :-) > > Es gibt Sprachen, die haben deine Idee einfach aufgegriffen :-) Verdammt! Ich dachte schon, ich hätte auch mal eine revolutionäre Idee. :-)
Norbert schrieb: > Ein T. schrieb: >> Aber dann könnte man sich diesen ganzen End[...]-Krams doch gleich >> ersparen und nur mit Einrückungen arbeiten. :-) > > Uuuhhh, ich sehe einen Sturm seltsamer Färbung aufziehen… ;-) Nach eingehender, tiefschürfender und umfangreicher Recherche vermute ich: er schlängelt eher, dieser Sturm. :-)
Ob S. schrieb: > Nunja, Pascal hat es meines Wissens nach niemals zu einem offiziellen > Standard gebracht. Genaugenommen schon: - Standard Pascal: ANSI/IEEE770X3.97-1993 oder ISO 7185:1990; - Extended Pascal: ANSI/IEEE770X3.160-1989 oder ISO/IEC 10206:1991; - https://de.wikipedia.org/wiki/Pascal_(Programmiersprache)#Standards - https://www.cs.utexas.edu/users/novak/iso7185.pdf Ob S. schrieb: > War allerdings dafür von vornherein auf bessere *Menschen*-Lesbarkeit ausgelegt Das kann man sich durchaus darüber streiten. Gerade durch seine extreme "Geschwätzigkeit" finde ich Pascal eher unübersichtlich. Ganz zu schweigen von den Wunden Fingern, von den endlos viele unnütz langen begin/end/then usw. die da getippt werden müssen. Z.B. das "verstecken" der Variablendeklarationen am Anfang und nicht dort wie sie hingehören, finde ich Pers. extrem nervig. C/C++ mag da genau das Gegenteil davon sein und gelegentlich fast schon etwas zu "Kurzform". Aber mit etwas Disziplin beim Schreiben/Einrücken, finde ich, schneller und besser zu lesen als Pascal. Ist aber wohl alles eine Frage der täglichen Übung. Gegen blödsinnige Variablen- und Funktionsnamen usw. sind jedenfalls beide nicht geschützt.
Ob S. schrieb: > Immerhin gibt es aber für C zumindest einen Art Standard, später sogar > einen echten Standard. Die ISO/IEC 9899 gibt es seit nunmehr 33 Jahren. > Problem ist nur: inzwischen ist das auch schon wieder wesentlich mehr > als nur einer. Nein, es gibt nur den einen. Dieser wird zwar alle paar Jahre mal aktualisiert (wie praktisch jede Norm, nicht nur im Computerbereich), mit jeder Neuauflage werden aber die vorangegangen ungültig. Anders als bei Pascal, wo die Standardisierung (ISO 7184 und ISO 10206) vonseiten der Compilerhersteller wenig Beachtung fand und schon bald wieder aufgegeben wurde, halten sich die gängigen C- und C++-Compiler recht gut an den Standard.
Irgend W. schrieb: > Ob S. schrieb: >> War allerdings dafür von vornherein auf bessere *Menschen*-Lesbarkeit ausgelegt > Das kann man sich durchaus darüber streiten. Gerade durch seine extreme > "Geschwätzigkeit" finde ich Pascal eher unübersichtlich. Es ist eigentlich ganz einfach: Wer eine Sprache gelernt hat¹ und sich damit beschäftigt, kann Programme in dieser Sprache auch problemlos lesen. Wer die Sprache nicht gelernt hat, kann beim Lesen von Code allenfalls erahnen, was dieser tut. Das ist zwar besser als gar nichts, hat aber keinerlei praktischen Nutzen. Ich persönlich kann zwar ein antikes Pascal-Programm aus Wirths Zeiten problemlos lesen, weil ich das irgendwann mal gelernt habe. Bei einem Programm in modernem Object-Pascal, das über Lehrbuchniveau hinausgeht, habe ich aber keine Chance, weil ich mich nie intensiv damit beschäftigt habe. Umgekehrt ist es nicht verwunderlich, dass jemand, der immer nur in Pascal programmiert hat, Schwierigkeiten beim Lesen von C- oder gar C++-Code hat. ──────────── ¹) Damit meine ich nicht das Anschauen eines 5-Minuten-Hipster-Videos zu dem Thema.
Yalu X. schrieb: > Nein, es gibt nur den einen. Dieser wird zwar alle paar Jahre mal > aktualisiert (wie praktisch jede Norm, nicht nur im Computerbereich), > mit jeder Neuauflage werden aber die vorangegangen ungültig. OK. Schöne Sache. Und wieso wird dann soviel Code "unbrauchbar", wenn man ihn mit einem neueren "Standard" übersetzt? Das sagt doch eigentlich alles über die Sprache und deren Standards aus.
Falk B. schrieb: > Max M. schrieb: >> Was mir aber immer wieder auffällt, das in Russland Pascal offenbar >> aktiver genutzt wird als woanders. > > Die fliegen auch noch mit Rakten aus den 1970er Jahren ins Weltall. > Das passt dazu! Echt russisch halt! ;-) Strukturierter Text bei der SPS Programmierung ist dann auch Russisch ^^. Das basiert auch auf Pascal. Und btw. Die Amis haben bis vor paar Jahren (oder tun sie es immer noch?) Sowjetische Raketenantriebe gekauft.
Ob S. schrieb: > Yalu X. schrieb: > >> Nein, es gibt nur den einen. Dieser wird zwar alle paar Jahre mal >> aktualisiert (wie praktisch jede Norm, nicht nur im Computerbereich), >> mit jeder Neuauflage werden aber die vorangegangen ungültig. > > OK. Schöne Sache. Und wieso wird dann soviel Code "unbrauchbar", wenn > man ihn mit einem neueren "Standard" übersetzt? Welchen Code meinst du konkret? Wenn es Probleme bei der Portierung von alten auf neue Plattformen gibt, liegt das i.Allg. nicht an der Sprache C/C++, sondern an irgendwelchen verwendeten Bibliotheken oder Frameworks, die ebenfalls aktualisiert wurden und die inkompatibel zu den alten Versionen sind, weil sie eben nicht standardisiert wurden.
Yalu X. schrieb: > in2out1.pas:program CopyInputToOutput; > var > c: char; > begin > while not eof do > begin > read(c); > write(c) > end > end. > > O je, so viel Code für so eine einfache Aufgabe. Zudem scheint er > zweimal zu beginnen und zweimal zu enden, was schon sehr komisch > aussieht. > > Nun dasselbe Programm für den erweiterten FPC: > > in2out2.pas:main = interact id Das obere Beispiel gibt immerhin einen Hinweis auf das was es tut und das auch fuer Laien. Die angeblich bessere untere Zeile ist zwar kuerzer, aber kryptisch. Wartbarkeit, wenn Bedeutung vergessen, gleich Null. Ich sehe hier eher einen gewaltigen Rueckschritt. Das Zeug ist nicht lesbar.
Yalu X. schrieb: > Welchen Code meinst du konkret? Also das würde die Grenzen des Forums definitiv sprengen. Und ich bin absolut sicher: Du weißt das auch ganz genau. > Wenn es Probleme bei der Portierung von alten auf neue Plattformen gibt, > liegt das i.Allg. nicht an der Sprache C/C++, sondern an irgendwelchen > verwendeten Bibliotheken oder Frameworks, die ebenfalls aktualisiert > wurden und die inkompatibel zu den alten Versionen sind, weil sie eben > nicht standardisiert wurden. Es liegt daran, das dieser "includierte" Code genau das ursprüngliche Problem hat: War zur Zeit seiner Verfassung absolut standargerecht, ist es aber nach dem neueren Standard eben nicht mehr. Nicht der Code ist das Problem, sondern die Änderung des Standards. Ist ja auch logisch: Wenn es Code gibt, der jemals nach irgendeinem Standard valid war, darf es keine Änderung des Standards geben, die ihn invalid macht. Wenn eine solche Änderung des Standards unumgänglich ist, um ein neues Feature umzusetzen, ist das nach den Gesetzen der Logik ein absolut eindeutiger Nachweis, dass die ursprüngliche Definition der Sprache unzureichend und die vorherigen Standards huppse waren. So einfach ist das. Klar, dass du das nicht wahrhaben willst. Aber isso.
Joe schrieb: > Das obere Beispiel gibt immerhin einen Hinweis auf das was es tut und > das auch fuer Laien. Dann lege den Code doch einmal jemandem vor, der noch nie etwas mit Programmierung zu tun hatte. Der wird (ohne weitere Erläuterungen) bei beiden Beispielen nur Bahnhof verstehen. Im Pascal-Code wird er trotz seiner Englischkenntnisse spätestens beim "char" steckenbleiben, weil er sich nicht sicher ist, ob damit die Holzkohle, die Putzfrau oder der Saibling gemeint ist. Ganz abgesehen davon wird Programmcode nicht für Laien geschrieben, sondern für Kollegen, die der jeweiligen Sprache bereits mächtig sind. > aber kryptisch. Für dich kryptisch. > nicht lesbar. Für dich nicht lesbar. Zeige einem Chinesen einen deutschen Text, dann wird er dich vielleicht darauf hinweisen, dass das Ganze auf chinesisch nicht nur leichter lesbar, sondern darüberhinaus auch noch deutlich kürzer ist. Das ist alles eine Frage der Perspektive, s. auch hier: Yalu X. schrieb: > Es ist eigentlich ganz einfach: > ...
Ob S. schrieb: > Yalu X. schrieb: > >> Welchen Code meinst du konkret? > > Also das würde die Grenzen des Forums definitiv sprengen. Du sollst ja nicht den kompletten Quellcode posten. Ein Hinweis, woher du diese Information hast, oder ein Link auf ein Open-Source-Projekt, wo dies zu einem großen Problem wurde, würde schon genügen. > Und ich bin absolut sicher: Du weißt das auch ganz genau. Ehrlich gesagt nicht, sonst hätte ich nicht gefragt. > Es liegt daran, das dieser "includierte" Code genau das ursprüngliche > Problem hat: War zur Zeit seiner Verfassung absolut standargerecht, ist > es aber nach dem neueren Standard eben nicht mehr. Es gibt wohl kaum eine Programmiersprache, bei deren Standardisierung mehr Wert auf Abwärtskompatibilität gelegt wird als bei C und C++. Kompatibilitätsprobleme sind deswegen höchstens eine Randerscheinung und erfahrungsgemäß auch meist sehr schnell behoben.
Yalu X. schrieb: > Es gibt wohl kaum eine Programmiersprache, bei deren Standardisierung > mehr Wert auf Abwärtskompatibilität gelegt wird als bei C und C++. Kunststück: Es gibt ja kaum Programmiersprachen, bei denen man mit mehreren Standards zu kämpfen hat. Im Übrigen ist die Bemühung um Abwärtskompatibilität sicher vorhanden und war sogar jeweils auch extrem wichtiges Design-Ziel, aber... Hat nicht wirklich geklappt! > Kompatibilitätsprobleme sind deswegen höchstens eine Randerscheinung und > erfahrungsgemäß auch meist sehr schnell behoben. Nur für die, die die Zeit haben, sich mit dem jeweils heissesten Schice der Sprache auseinander zu setzen. Und obendrein mit der Historie der Sprache, als die gerade der heisseste Schice war, jedenfalls für den Programmierer des unwilligen Quelltextes. Der ist sicher nicht Schuld, denn er konnte nicht in die Zukunft sehen. Die Arschkarte haben die Leute gezogen, die den damaligen Code eben heute benutzen müssen. C bietet "Portabilität"... Da lach' ich drüber. C kann nicht mal Portabilität für den eigenen Code bieten. Und noch viel ärger wird es, wenn man auch noch den Compiler wechseln muß. Auch die haben (und hatten) immer mal wieder doch leicht verschiedene Interpretationen des jeweils gültigen Standards. Das sorgt auch immer wieder mal für etwas Spaß...
Irgendwie klingt das ein bisschen wie der Fanatismus von "moby". Warum nur?
Ob S. schrieb: > Yalu X. schrieb: > >> Es gibt wohl kaum eine Programmiersprache, bei deren Standardisierung >> mehr Wert auf Abwärtskompatibilität gelegt wird als bei C und C++. > > Kunststück: Es gibt ja kaum Programmiersprachen, bei denen man mit > mehreren Standards zu kämpfen hat. Wenn du mit "mehrere Standards" überarbeitete und erweiterte Versionen ein und desselben Standards meinst: Solche Überarbeitungen gibt es für praktisch jede aktiv genutzte Sprache. Sie stellen somit keine C-spezifische Ausnahme, sondern die allgemeine Regel dar. > Im Übrigen ist die Bemühung um Abwärtskompatibilität sicher vorhanden > und war sogar jeweils auch extrem wichtiges Design-Ziel, aber... > > Hat nicht wirklich geklappt! IMHO hat das sogar erstaunlich gut geklappt. > Die Arschkarte haben die Leute gezogen, die den damaligen Code eben > heute benutzen müssen. Du sprichst in der dritten Person, d.h. du kennst die vermeintlichen Probleme nur vom Hörensagen. Das erklärt natürlich auch, dass du keine konkreten Beispiele nennen kannst, die deine Behauptungen untermauern könnten.
:
Bearbeitet durch Moderator
Yalu X. schrieb: > Du sprichst in der dritten Person, d.h. du kennst die vermeintlichen > Probleme nur vom Hörensagen. Also das ist wohl unter "drastischer Fehlschluß" einzuordnen. Nein, klar bin ich auch perönlich von diesem Mist betroffen. War es in der Vergangenheit mehrfach und kämpfe gerade aktuell (mal wieder) mit so einem Problem. > Das erklärt natürlich auch, dass du keine > konkreten Beispiele nennen kannst, die deine Behauptungen untermauern > könnten. Nein. die Erklärung dafür ist viel einfacher: Das ist alles kein OpenSource. Und darf/soll es auch nicht werden. Dies zu entscheiden obliegt nicht mir, sondern meinen Brötchengebern. So einfach ist das. Wenn du sowas nicht kapierst, bist du schlicht blöd. Sorry, aber ist so.
Jens B. schrieb: > Und btw. Die Amis haben bis vor paar Jahren (oder tun sie es immer > noch?) Sowjetische Raketenantriebe gekauft. Sicher nicht, denn die Sowjetunion gibt es seit über 30 Jahren nicht mehr. Wohl aber Russland. Ja, die Amis haben ne Menge russische Triebwerke gekuft, weil die sehr gut und scheinbar auch preiswert sind. Jetzt will man diese Geschäftsbeziehung eher lösen und nur noch Made in USA kaufen, vornehmlich bei SpaceX. Naja.
Ob S. schrieb: > War es in der > Vergangenheit mehrfach und kämpfe gerade aktuell (mal wieder) mit so > einem Problem. Du behauptest also ernsthaft, daß ein aktueller C-Compiler keinen alten C-Code übersetzen kann?
Moin, Ich habe einige ältere Arduino Projekte mit alten ASM Bibliotheken drin, die in neueren Versionen von GCC nicht mehr funktionieren. Die Originalprojekte bauten vollkommen Fehlerfrei unter V5.4.0. Bei den späteren Versionen gab es nur noch jede Menge Fehler durch die ASM Bib. Auch neuere, angepasste Versionen der ASM Bib. machten Schwierigkeiten oder liefen, obwohl kompilierbar, nicht mehr einwandfrei. Es ist durchaus möglich, daß Experten, vielleicht besondere C.L. switches kennen, mit denen man die Probleme eliminieren könnte, aber da kenne ich mich einfach nicht genug aus um da selber folgerichtig auf den Grund der zahlreichen Probleme zu kommen. Und dafür wäre mir auch die Zeit zu schade. Es erschließt sich mir nicht unbedingt, warum der Compiler nicht selbständig Hinweise geben könnte, welche Einstellungen für Kompatibilität dann notwendig wären. Mir werden diese andauernde nicht-kompatiblen Versionen nach Versions-Update einfach zu lästig. Meine Lösung für diese paar ältere Projekte war, einfach eine portable Version der IDE mit den korrekten Versionen anzufertigen, die nicht durch Updates modifiziert werden können, und alles ist gut. Die für ein Projekt im IDE festgelegte Version wird übrigens durch die verwendete Bord Package maßgeblich festgelegt. Man muß im Quellcode einen Hinweis reinschreiben, daß das Projekt nur bis zu einer bestimmten Bordversion kompatibel ist. Wenn man sich dann in den IDE Ordnern umschaut, sieht man bei mir z.B. drei verschiedene eingebaute GCC Versionen. Aber das andauernde Umstellen ist nicht wirklich zweckmässig. Am besten ist es mit portablen IDE Versionen zu arbeiten. Dann bleibt alles beim Alten und lässt sich auch besser archivieren. Ich versuche zwar, neue Projekte immer mit der aktuellen Version zu bauen, aber es ist bei alten Projekten zweckmässiger mit der ursprünglich benutzten IDE/GCC Konserve zu arbeiten. Man sollte im Quell Informations Block immer alle Bau- und Versionshinweise reinschreiben, so daß man sich nötigenfalls alles von dort wieder so herrichten kann. Auch alle HW Besonderheiten sollten dort mit drinstehen. Ich halte es so, daß mir der Quellcode immer alle nötigen besonderen Informationen zum Bau der SW komplett enthält. Ich hatte dasselbe Problem auch bei der PIC CCS Compiler Familie, daß alte Projekte ohne Anpassungen nicht mehr fehlerfrei erzeugbar waren. Auch da ist es am Besten, immer den ursprünglich benutzen Compiler bei Nacharbeiten zu wählen. Deshalb immer die frühen Compiler archivieren, wenn man Altes pflegen will. Gerhard
Ob S. schrieb: > Yalu X. schrieb: > ... >> Das erklärt natürlich auch, dass du keine konkreten Beispiele nennen >> kannst, die deine Behauptungen untermauern könnten. > > Nein. die Erklärung dafür ist viel einfacher: Das ist alles kein > OpenSource. Und darf/soll es auch nicht werden. Anstatt Quellcode zu posten, könntest du ja einfach ein paar von euch häufig genutzte C-Features benennen, die nach ISO 9899:1990 noch standardkonform waren, es heute (ISO 9899:2018) aber nicht mehr sind. Ja, es gibt ein paar kleinere Inkompatibilitäten zwischen C90 und dem aktuellen Standard. Es würde mich aber sehr wundern, wenn diese in eurem realen Code tatsächlich auftreten und euch das Leben so schwer machen, dass du die ganze Welt an eurem Problem teilhaben lassen musst.
Gerhard O. schrieb: > Ich habe einige ältere Arduino Projekte mit alten ASM Bibliotheken drin, > die in neueren Versionen von GCC nicht mehr funktionieren. C++-Code mit Assemblermodulen sind eine andere Geschichte. Von Zeit zu Zeit wird das ABI des C++-Compilers geändert. Dies führt zwar selten zu Inkompatibilitäten, aber wenn doch, muss der komplette C-Code eines Programms (einschließlich verwendeter Bibliotheken) neu kompiliert sowie die Assemblermodule entsprechend angepasst und neu assembliert werden. Beim GCC sollte das seit 3.4.0 eigentlich nicht mehr erforderlich sein, aber vielleicht enthalten die von dir verwendeten Assembler-Bibliotheken Fehler, die erst im Zusammenhang mit neueren Compiler-Versionen in Erscheinung treten. Wie auch immer: Für Probleme mit Assemblermodulen kann nicht der C-Standard verantwortlich gemacht werden.
Yalu X. schrieb: > Gerhard O. schrieb: >> Ich habe einige ältere Arduino Projekte mit alten ASM Bibliotheken drin, >> die in neueren Versionen von GCC nicht mehr funktionieren. > > C++-Code mit Assemblermodulen sind eine andere Geschichte. > > Von Zeit zu Zeit wird das ABI des C++-Compilers geändert. Dies führt > zwar selten zu Inkompatibilitäten, aber wenn doch, muss der komplette > C-Code eines Programms (einschließlich verwendeter Bibliotheken) neu > kompiliert sowie die Assemblermodule entsprechend angepasst und neu > assembliert werden. > > Beim GCC sollte das seit 3.4.0 eigentlich nicht mehr erforderlich sein, > aber vielleicht enthalten die von dir verwendeten Assembler-Bibliotheken > Fehler, die erst im Zusammenhang mit neueren Compiler-Versionen in > Erscheinung treten. > > Wie auch immer: Für Probleme mit Assemblermodulen kann nicht der > C-Standard verantwortlich gemacht werden. Ich kann mich momentan nicht erinnern, welche Art die Fehlermeldungen waren und von wem. Ich schaue mir das vielleicht wieder einmal an mit der aktuellen Version und berichte, wenn's interessiert. Die Bib ist übrigens die I2C-Master-SoftMaster oder so ähnlich. ...
Yalu X. schrieb: > Ja, es gibt ein paar kleinere Inkompatibilitäten zwischen C90 und dem > aktuellen Standard. Es würde mich aber sehr wundern, wenn diese in eurem > realen Code tatsächlich auftreten und euch das Leben so schwer machen, > dass du die ganze Welt an eurem Problem teilhaben lassen musst. Vor allem kann man ja sogar auf Dateiebene sagen welchen "Dialekt" der Compiler verstehen soll...wenn man will...und das build system das kann... Der Compiler ist sicher nicht (extreme sonderfälle ausgenommen) das Problem. Alle mir bekannten können eigentlich alle gängigen "Entwicklungsstufen". Aus halbwegs aktueller Erfahrung: c89 Code compiliert immer noch, wenn man im makefile auch c89 angibt :) Siehe auch hier: https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/C-Dialect-Options.html 73
Harald K. schrieb: > Irgendwie klingt das ein bisschen wie der Fanatismus von "moby". > > Warum nur? Natürlich aus Gründen. Aus Gründen, die so unfaßbar geheim sind, daß unser Held nicht einmal ein Minimum Working Example zur Erklärung seiner steilen Thesen daraus bauen kann. Er hat kein Argument, aber Recht!!eins1elfeins!!
Was Kompatibilität betrifft, denke ich an meine Nischen- Programmiersprache, die ich schon 30 Jahre lang nutze. Der Hauptgrund war der, daß man alte Quelltexte, die im Forum oder auch auf der eigenen Platte oder USB-Stick vorhanden sind, ausführen konnte. Wenn man dann den Algo brauchen konnte, konnte man ihn immer noch auf die neue Syntax umstricken. Somit ersparte man sich unnötige Mühe, wenn es dann doch nicht das richtige war. Der Autor (Ein-Mann-Projekt) hatte immer sehr großen Wert auf Abwärtskompatibiltät gelegt. Da gingen alte Befehl/Funktionen immer noch einige Versionen weiterhin. Der Parser des Interpreters/Runtimemodul erkannte die alte Funktion/Befehl und hatte es erst in die neue Syntax umgewandelt, die auch dann der neue Compiler verarbeiten konnte. Außerdem stehen bei jedem Befehl/Funktion die Compilerversionen, also ab wann der Befehl/Funktion verfügbar ist. Und wenn er es mit dem Parser mal wirklich nicht auflösen konnte, stand das auch in der Hilfe, daß z.b. dieser alte Befehl/Funktion nicht mehr geht. Von Zeit zu Zeit gab er alte Versionen als Freeware frei und damit verschwanden dann auch langsam die Uralt-Befehle/Funktionen, die er dann rausnahm. Ein sehr guter Einfall von ihm war damals das Thema Operatoren. In den Anfangsjahren verstand die Sprache keine (+ - / *). Alles wurde über Funktionen realiseiert (Add(N1, N2), Add$(S1, S2) SUB(N1,N2), DIV(N1,N2), MUL(N1,N2) ). Mit Einführung der normalen Operatoren (+, -, /, *) hat er dann einen Interpreter/Compilerschalter $O+ eingebaut. Der Parser hatte dann in die neue Syntax übersetzt. Auch eine Includedatei hatte er dafür vorbereitet. so etwa : Proc Add Parameters n1%, n2% Return n1% + n2% EndProc Wenn man da so eine Monsterzeile mit ADD() Sub() usw. und dann noch mehrfach ineinander verschachtelt, umstricken wollte, kostete das schon einige Mühe. Schade eigentlich, daß er nun wegen Alters (70+) aufhört. Für kleine Tools / Programme nutze ich es bis heute immer noch gerne. Halt gerade deshalb, weil man damit flott etwas kleines gestrickt bekommt und kein Monster anwerfen muß. Was ich damit nur sagen wollte, ist, daß er hinsichtlich der Kompatibiltät sehr vorbildlich war.
:
Bearbeitet durch User
Angehängte Dateien:
Hallo, Yalu X. schrieb: > Ja, es gibt ein paar kleinere Inkompatibilitäten zwischen C90 und dem > aktuellen Standard. ..die aber keine wirklichen Probleme darstellen, denn... Hans W. schrieb: > Vor allem kann man ja sogar auf Dateiebene sagen welchen "Dialekt" der > Compiler verstehen soll...wenn man will...und das build system das > kann... ...siehe Anhang, hier die Wahlmöglichkeiten (aus Code::Blocks) nach welchem Standard nun ein C- b.z.w C++-Quellcode übersetzt werden soll. rhf
Beitrag #7528880 wurde von einem Moderator gelöscht.
Beitrag #7528883 wurde von einem Moderator gelöscht.
Harald K. schrieb: > wird bald ein Zustand erreicht, in > dem jeder Programmierer seine ihm eigene und für alle anderen > weitestgehend unverständliche Programmiersprache einsetzt. Den Zustand bzw. die Möglichkeit dafür gibt es schon seit dem es Forth gibt :-)
Nun, in Sachen "write-only-language" wird Forth vermutlich nur von Brainfuck getoppt.
Heinz B. schrieb: > meine Nischen- > Programmiersprache (X)Profan? Habe ich auch jahrelang benutzt. Bin jetzt auf PureBasic umgestiegen. Gruss Chregu
Christian M. schrieb: > (X)Profan? Habe ich auch jahrelang benutzt. Bin jetzt auf PureBasic > umgestiegen. Ja, genau. PureBasic hatte ich auch mal eine zeitlang benutzt. Ist mir aber wegen den verschachtelten Eventabfragen für ein Fenster zu fummelig. Auch die Debugausgaben, um kurz was auszugeben sind nicht so meins. Für mein Kleinzeugs reicht mir deshalb auch XProfan.
Harald K. schrieb: > Nun, in Sachen "write-only-language" wird Forth vermutlich nur von > Brainfuck getoppt. Naja, avr gcc inline Assembler kommt da auch ganz gut ran ;-)
Falk B. schrieb: > Harald K. schrieb: >> Nun, in Sachen "write-only-language" wird Forth vermutlich nur von >> Brainfuck getoppt. > > Naja, avr gcc inline Assembler kommt da auch ganz gut ran ;-) Nur dass es sich bei Inline Assembler nicht um eine Programmiersprache handelt, sondern nur um ein Interface um zwei verschiedene Sprachen miteinander zu verbinden.
Wenn ich's mir so recht überlege, hat mich PASCAL doch recht lange begleitet: In den 80ern auf meinem Alphatronic-PC unter CP/M (nachdem mir Basic allmählich auf den S*** ging), später am Gymnasium im Informatikkurs auf Apple-IIe, und noch etwas später an der Uni bei den ersten Progammieraufgaben (wir konnten Pascal oder C verwenden), und irgendwann im ~3 Semester dann in Form der Totgeburt Oberon. In den späteren Semestern war dann PASCAL kein Thema mehr. Im Rückblick muss ich sagen, eigentlich keine schlechte Sprache, wenn auch etwas geschwätzig. Aber angesichts von C++, Python und RUST sehe ich heute keinen Anlass mehr, mich mit PASCAL zu beschäftigen, nicht mal aus Sentimentalität.
Vancouver schrieb: > Im Rückblick muss ich sagen, eigentlich keine schlechte Sprache, wenn > auch etwas geschwätzig. Und das auch nur, solange man damit akademische Probleme im Schule oder Studium lösen muß. Vancouver schrieb: > 3 Semester dann in Form der Totgeburt Oberon Da war doch eigentlich das genauso tote Modula angesagt. Oliver
Oliver S. schrieb: > Und das auch nur, solange man damit akademische Probleme im Schule oder > Studium lösen muß. Wenn man sich anschaut, was damals sonst so in Mode war, COBOL, FORTRAN, BASIC, dann war Pascal da schon Lichtjahre voraus. Aber die Dinosaurier waren damals noch lebendig, deswegen kam Pascal nicht so recht in die Puschen. Modula wurde zumindest da und dort verwendet, meistens in akademischen Projekten. Oberon ist schon auf der Startrampe explodiert. Dummerweise habe ich daneben gestanden, einer meiner Profs war damals unendlich begeistert davon, hat aber später selbst zugegeben, dass das ein Irrtum war. Das Einzige was mir an Oberon gut gefallen hat, war, dass es nur ein einziges Schleifenkonstrukt gab, nämlich loop/exit/end. Damit konnte man alle erdenklichen Schleifen bauen, und der Overhead gegenüber for, while, do usw. war minimal.
Vancouver schrieb: > Das Einzige was mir an Oberon gut gefallen hat, war, dass es nur ein > einziges Schleifenkonstrukt gab, nämlich loop/exit/end. Das ist in C oder anderen Sprachen nicht anders, nur mit etwas mehr syntaktischem Zucker verschönert. Oliver
Vancouver schrieb: > Aber angesichts von C++, Python und RUST sehe > ich heute keinen Anlass mehr, mich mit PASCAL zu beschäftigen, nicht mal > aus Sentimentalität. Das habe ich auch mal gedacht, bis ich auf Lazarus gestossen bin. ;-)
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.