Habe ein Hauptprojekt (PC Programm) geschrieben in Pascal. Pascal als Sprache gefällt mir sehr gut. Fange jetzt an die dazugehörigen AVR Mikrocontroller ebenfalls mittels Pascal zu programmieren. Mit mikroPascal http://www.mikroe.com/mikropascal/avr Das geht ganz gut. Parallel dazu denke ich schon über einen Umstieg auf ARM Controller nach. Die Firma bietet ebenfalls einen Pascal Compiler für ARM Prozessoren an. Allerdings wird momentan nur STM32 uns Stellaris unterstützt. Die Bibliotheken (Uart, Ethernet, usw.) sind wohl nicht quelloffen, jedenfalls habe ich bei einigem Suchen keine Quellen der Bibliotheken des ARM Compilers von Mikroelektronika gefunden. Vielleicht sind es ja übersetzte C Programme in Binärform, da die Firma ja auch C Compiler anbietet. Ich überlege jetzt evtl. auf C umzusteigen bevor es "zu spät" ist. Für C gibt es ja auf Linux freie Compiler. Ich habe schon mal in C programmiert, allerdings finde ich es nicht unbedingt die bessere Sprache. Man kann in Pascal ebenfalls alles das machen was in C geht. Habe schon in Freepascal für ARM compiliert. Auf einem Linux PC. http://www.freepascal.org Das ging irgendwann nach langem hin und her. Das ist aber wohl ebenfalls noch nicht 100% ausgereift. Was spricht für C?
Rainer S. schrieb: > Was spricht für C? Dass es die Standardsprache im Mikroprozessorbereich ist. Wenn du anstrebst, das professionell zu machen, also irgendwas in die Richtung zu lernen oder zu studieren, dann solltest du dich mit C beschäftigen. Privat geht auch Pascal, auch wenn ich persönlich nicht dazu raten würde.
Hallo, Pascal ist nicht nur eine Frage des persönlichen Geschmacks (ich programmiere seit 1980 mit Pascal und gebe es jetzt weitgehend auf). Du brauchst für die Benutzung von Fremdsoftware immer "Bindings", z.B. Definitionsdateien für die Funktionen einer DLL, und die bekommst du generell in C, nur sehr selten in Pascal. Selbst für Windows sind längst nicht alle APIs in Pascal definiert, die muss man dann selbst schreiben und das ist eine ganz erhebliche Mehrarbeit gegenüber C/C++ (Es dreht sich da um Aberhunderte von Funktionsdeklarationen!). Dazu kommt, dass Borland und Nachfolger Embarcadero sehr "geschäftstüchtig" mit Lizenzen umgehen, mir sind durch einen Fehler bei Embarcadero alle Updatemöglichkeiten gestrichen worden und ein Neukauf würde einige Tausender kosten, was nicht nur nicht wirtschaftlich wäre, ich lasse mich auch aus Prinzip nicht gern betrügen, daher wird Delphi nicht mehr eingesetzt. Also eindeutige Aussage: C, C++, und wenn man MS mag auch C#. Gruss Reinhard
Dussel schrieb: > Wenn du > anstrebst, das professionell zu machen, also irgendwas in die Richtung > zu lernen oder zu studieren, dann solltest du dich mit C beschäftigen. > Privat geht auch Pascal, auch wenn ich persönlich nicht dazu raten > würde. Ich behaupte mal, dass ich das schon lange professionell mache. Wie gesagt habe ich auch mal in C geschrieben, aber das hat mir nicht so 100% zugesagt. Michael Reinelt schrieb: > http://www.pbm.com/~lindahl/real.programmers.html Da stehen allerhand Sachen drin. Sieht ziemlich dogmatisch aus. Reinhard Kern schrieb: > Pascal ist nicht nur eine Frage des persönlichen Geschmacks (ich > programmiere seit 1980 mit Pascal und gebe es jetzt weitgehend auf). Und das ganze Know-how, welches Du in Form von Pascal Quellcode angesammelt hast? Auf Deiner Seite steht, dass das nicht verloren gehen sollte. > Du > brauchst für die Benutzung von Fremdsoftware immer "Bindings", z.B. > Definitionsdateien für die Funktionen einer DLL, und die bekommst du > generell in C, nur sehr selten in Pascal. So selten ist das gar nicht. Die meiste Software schreibe ich selbst. An Fremdsoftware benutze ich dann so ganz grundlegende Sachen wie das Betriebssystem oder die Funktionalität des Browsers (der schon da ist). > Selbst für Windows sind längst > nicht alle APIs in Pascal definiert, die muss man dann selbst schreiben > und das ist eine ganz erhebliche Mehrarbeit gegenüber C/C++ (Es dreht > sich da um Aberhunderte von Funktionsdeklarationen!). In Freepascal ist Windowsprogrammierung überhaupt kein Problem. Die Sachen sind alle schon (einmal) definiert worden. Win 32, Win 64 und sogar Win CE wird unterstützt. > Dazu kommt, dass Borland und Nachfolger Embarcadero sehr > "geschäftstüchtig" mit Lizenzen umgehen, mir sind durch einen Fehler bei > Embarcadero alle Updatemöglichkeiten gestrichen worden und ein Neukauf > würde einige Tausender kosten, was nicht nur nicht wirtschaftlich wäre, > ich lasse mich auch aus Prinzip nicht gern betrügen, daher wird Delphi > nicht mehr eingesetzt. Vollwertige Alternative: Freepascal. Ich denke mit wenigen Anpassungen (wenn überhaupt) kannst Du Deine Quellen 1:1 weiterverwenden. Von der Mailingliste her weiß ich, dass auf Kompatibilität mit Delphi viel Wert gelegt wird. Meiner Meinung nach zu viel. > > Also eindeutige Aussage: C, C++, und wenn man MS mag auch C#. In MS habe ich kein Vertrauen. Ich programmiere wenn es eben geht für Linux. Was ich mir wünschen würde wäre ein Compiler, der beides kann. Das sollte ja eigentlich machbar sein. Die Mikroelektronika Leute machen ja beides. http://www.mikroe.com/compilers Das wäre ein Novum.
Rainer S. schrieb: > Michael Reinelt schrieb: >> http://www.pbm.com/~lindahl/real.programmers.html > > Da stehen allerhand Sachen drin. Sieht ziemlich dogmatisch aus. Dann hast du nicht verstanden,warum es beim 'real programmer' in Wirklichkeit geht. > Reinhard Kern schrieb: >> Pascal ist nicht nur eine Frage des persönlichen Geschmacks (ich >> programmiere seit 1980 mit Pascal und gebe es jetzt weitgehend auf). > > Und das ganze Know-how, welches Du in Form von Pascal Quellcode > angesammelt hast? Auf Deiner Seite steht, dass das nicht verloren gehen > sollte. Das richtige Know-How sammelt sich in Form von Algorithmen an und nicht in Form von Quellcode. Die sind dein 'Schatz'. Code ist nur eine konkrete Umsetzung von Algorithmen und lässt sich in jeder beliebigen Sprache aus demselben Paradigmenbereich in kurzer Zeit neu schreiben. Zum Rest: Du hast dir deine Meingung ja sowieso schon einzementiert. Du willst bei Pascal bleiben. Ist auch ok. Aber wozu fragst du dann?
Rainer S. schrieb: > Und das ganze Know-how, welches Du in Form von Pascal Quellcode > angesammelt hast? Auf Deiner Seite steht, dass das nicht verloren gehen > sollte. Und eben, damit das anderen NICHT passiert, empfehle ich Pascal nicht mehr. Ich mache auch viel Embedded, da ist die Nichtverfügbarkeit von Pascal noch viel krasser als auf dem PC. Ich habe auch keine Bedenken, verschiedene Sprachen in einem Projekt zu kombinieren, aber das scheint wohl aus der Mode zu kommen, viele Systeme unterstützen das nicht mehr, weil sie kein standardisiertes Object-Format verwenden oder weil Änderungen des Makefiles, sofern vorhanden, nicht vorgesehen sind. Meiner Einschätzung nach verschwindet Pascal nicht schlagartig, aber so allmählich wird der Marktanteil unter 1% sinken und es wird nur noch als antik oder exotisch besprochen. Was das verlorene Knowhow angeht, ich habe mal mit ALGOL angefangen, das kennt heute schon niemand mehr. Verloren ist es trotzdem nicht, gelernt ist gelernt, eine vorhandene Problemlösung in Pascal kann ich natürlich in C/C++ umformulieren, das ist bloss Routinearbeit. Die Frage der Umstellung auf zukunftssichere Software hat sich übrigens schon länger gestellt, der Betrug durch Embarcadero hat jetzt den endgültigen Ausschlag gegeben. Es ist übrigens auch unter Marketingaspekten nicht so günstig, ein exotisches System zu verwenden, vielmehr ist durchaus denkbar, dass man ein Entwicklungsprojekt wegen der Verwendung von Pascal garnicht erst bekommt. Ein Kunde hat nämlich auch grosse Probleme, wenn er ein Pascal-Projekt an einen anderen Programmierer übertragen muss. Gruss Reinhard
Also wenn Du GUI machst, kommst Du im Moment fast nicht um Lazarus rum. (Pascal basierend) C erfordert eine gewisse Erfahrung und Disziplin, das sollte man erst nach einem Assembler machen. C++ ist eher was für Masochisten, die eine Sprache andauernd lernen wollen, und denen gutes Sprachdesign egal ist. C# ist halt wie VBA eine reine Microsoftsache und selbst für nur-Windows-Projekte eine eher schlechte Wahl. Wenn Du C machen willst, lies Dir erst mal "The Art of UNIX Programming" durch. http://www.faqs.org/docs/artu/ Das Buch stellt ein Regelwerk vor, dass Dir für C und andere Sprachen helfen kann. Das hilft Dir dabei bessere Softwaresysteme zu entwickeln. Auch außerhalb von UNIX. Das sind Gedanken von jemanden der schon mal gute Software geschrieben hat. Daran kann man sich halten, sollte es aber nicht sklavisch nachahmen. Man sollte meiner Meinung nach nicht C programmieren, ohne die Grundzüge dieses Buches verstanden zu haben. (Man kann da aber bewusst Dinge gezielt ignorieren.) Mir haben die Prinzipen aus dem Buch im letzten Arbeitszeugnis den Satz "Insbesondere mit der oben erwähnten Datenauswertesoftware hat er unserem Schlüsselprodukt zu einem absoluten Alleinstellungsmerkmal verholfen, von dem unser Unternehmen sehr profitiert." beschert.
Karl Heinz Buchegger schrieb: > Dann hast du nicht verstanden,warum es beim 'real programmer' in > Wirklichkeit geht. Zu seiner Entschuldigung sei gesagt, dass der Essay wohl ein gewisses Alter voraussetzt... wie sonst sollte man Anspielungen wie TRASH-80 verstehen :-) Zum Thema: Pascal ist eine Lehrsprache, und wurde auch dafür (und nur dafür) entwickelt. Dafür ist sie meiner Meinung nach auch recht gut geeignet (ich hab selbst mit Pascal programmieren gelernt). Ich hab nie verstanden wie man ernsthaft professionell Software damit entwickeln will... ich übrigen teile ich zu 150% die Meinung, dass Know-How in Algorithmen steckt, und nicht in Quellcode. Wer das anders sieht, ist wahrscheinlich mit einer Lehrsprache ganz gut bedient.
Karl Heinz Buchegger schrieb: > Zum Rest: Du hast dir deine Meingung ja sowieso schon einzementiert. Du > willst bei Pascal bleiben. Ist auch ok. Aber wozu fragst du dann? Vielleicht gibt es ja gute Argumente für C. Aber Du hast recht ich sitze da relativ fest im Sattel. Karl Heinz Buchegger schrieb: > Das richtige Know-How sammelt sich in Form von Algorithmen an und nicht > in Form von Quellcode. Die sind dein 'Schatz'. Code ist nur eine > konkrete Umsetzung von Algorithmen und lässt sich in jeder beliebigen > Sprache aus demselben Paradigmenbereich in kurzer Zeit neu schreiben. Ein Projekt von 50000 Zeilen Quellcode ist nicht mal eben so umprogrammiert, auch wenn es relativ einfach ist. Reinhard Kern schrieb: > Ich mache auch viel Embedded, da ist die Nichtverfügbarkeit von Pascal > noch viel krasser als auf dem PC. Mikroelektronika hat gute Pascal Compiler im Angebot und mit Freepascal (was Du Dir aber wohl nicht ansehen willst) kann man ebenfalls die ARM Prozessoren programmieren. Ich hatte zuerst Bedenken Freepascal zu benutzen, habe es aber bis heute nicht bereut. Die Quellen gebe ich üblicherweise nicht heraus. Christian Berger schrieb: > Also wenn Du GUI machst, kommst Du im Moment fast nicht um Lazarus rum. > (Pascal basierend) Ich benutze Lazarus. Michael Reinelt schrieb: > Zum Thema: Pascal ist eine Lehrsprache, und wurde auch dafür (und nur > dafür) entwickelt. Dafür ist sie meiner Meinung nach auch recht gut > geeignet (ich hab selbst mit Pascal programmieren gelernt). SMS war auch erst kostenlos. https://de.wikipedia.org/wiki/Short_Message_Service#Wirtschaftliche_Bedeutunghttps://de.wikipedia.org/wiki/Short_Message_Service#Wirtschaftliche_Bedeutung Michael Reinelt schrieb: > Ich hab nie verstanden wie man ernsthaft professionell Software damit > entwickeln will... Was verstehst Du daran nicht? Ehemaliger Arbeitgeber: http://www.ideco-gmbh.de Alle PC's mit Pascal programmiert.
Rainer S. schrieb: > Die Quellen gebe ich > üblicherweise nicht heraus. Mit anderen Worten, alle deine Software stirbt mit dir und die Kunden stehen mit ihrer Fehlinvestition im Regen. Da hast du natürlich recht, wenn man die Leute so über den Tisch zieht, kommt es auf C oder Pascal auch nicht mehr an. Ich dachte, du wärst ein seriöser Geschäftspartner. Gruss Reinhard
Rainer S. schrieb: > Karl Heinz Buchegger schrieb: >> Zum Rest: Du hast dir deine Meingung ja sowieso schon einzementiert. Du >> willst bei Pascal bleiben. Ist auch ok. Aber wozu fragst du dann? > > Vielleicht gibt es ja gute Argumente für C. Das einzige Argument ist, dass du mit C-Kentnissen höchst wahrscheinlich leichter einen Job findest. Anonsten: Pascal und C sind aus demselben Sprachparadigama und sind selbstverständlich Turing-vollständig. Was man mit der einen Sprache machen kann, kann man mit der anderen genauso. Wobei der Umstieg von Pascal (wir reden doch von Pascal so wie Wirth sich das im wesentlichen vorgestellt hat. Also keine objektorientierten Erweiterungen etc.) auf C gar nicht mal so wild ist. Die Syntax ist ein wenig anders, aber so radikal verschieden dann auch wieder nicht. Ob man jetzt zuweisungen mit := schreibt und Vergleiche mit = oder wie in C Zuweisungen mit = und dafür Vergleiche mit == ist im Grunde Jacke wie Hose. Pascal als Lehrsprache hat sich halt für das eine entschieden, während die C-Macher pragmatisch vorgegangen sind und sich gefragt haben, was in der täglichen Programmierarbeit oft getippt werden muss und diese Dinge besonders kurz formuliert haben. Du wirst am Anfang ein paar mal auf speziell diese Syntaxunterschiede reinfallen, genso wie ich drauf reinfallen würde, wenn ich mal wieder in Pascal programmieren würde. Aber letzten Endes ist es reine Gewohnheitssache. Wobei zugegebenermassen ein C Compiler vieles akzeptieren muss, weil es legales C ist, was ein Pascal Compiler brüsk zurückweisen würde. Die Programmiersprache ist nur das Werkzeug. Je besser du es beherrscht, desto besser kannst du Algorithmen damit umsetzen. > Ein Projekt von 50000 Zeilen Quellcode ist nicht mal eben so > umprogrammiert, auch wenn es relativ einfach ist. Es gibt ja auch Sprachkoverter (auch wenn ich schon lange keinen mehr in den Fingern hatte). Aber logisch. 50000 LOC übersetzt man nicht einfach so von heute auf morgen. Unter diesem Gesichtspunkt wirst du allerdings nie zu einer anderen Sprache wechseln. Denn egal was - dieses Problem hast du natürlich immer.
@Rainer Kennst Du das Prinzip der Schafherde? Da geht es nur darum, in welche Richtung die Masse läuft. Es interessiert niemanden, welches der richtige Weg ist. Wobei 20 Leute, wahrscheinlich 21 gut begründete Beschreibungen liefern können. Also egal was Du willst, mittelfristig bleibt dir nur Mäh! (C) zu rufen.
Amateur schrieb: > Es interessiert niemanden, welches der richtige Weg ist. Weil es bei dieser Fragestellung kein "richtig" oder "falsch" gibt. Und im Zweifel sagt dir dann schon der nächste Arbeitgeber, welche Sprachkenntnisse er von dir erwartet.
Für C spricht, dass Pascal nie über den Status einer akademischen Sprache hinaus kam. Sehr gut für die Lehre (zumindest vor ca. 20 Jahren), aber ohne Praxisrelevanz. Allerdings kannst du als reiner Bastler natürlich machen und ausprobieren, was du willst.
5-Sterne-Los schrieb: > Für C spricht, dass Pascal nie über den Status einer akademischen > Sprache hinaus kam. Sehr gut für die Lehre (zumindest vor ca. 20 > Jahren), aber ohne Praxisrelevanz. Aber Delphi/Lazarus ist alles andere als eine rein akademische Sprache. Sonst gäbe es wohl kaum solche Software hier: http://www.diptrace.com/
Also die Programmiersprache ist i.d.R. egal. Gut Klassiker: C: "shoot yourself in the foot" PASCAL: "the compiler wont let you shoot yourself in the foot" Wenn man C nach sinnvollen Paradigmen programmiert kann man den Code auch in PASCAL übersetzen, umgekehrt geht es IMMER ! Also kein Grund sich auf eine Sprache festzulegen. Wie Karlheinz schon erwähnt hat kommt es auf das Begreifen der Inhalte und Zusammenhänge an. Daher kann man ja auch aktuelle Probleme in "Pseudoprogrammiersprachen" packen oder gleich versuchen via UML das ganze einzukapseln. Meine persönliche Meinung ist daher das Du bei der PASCAL Vorgehensweise bleiben solltest und das ganze einfach in C/C++ umsetzen. Wobei C++ mehr Möglichkeiten bietet als Object-PASCAL ! Aber bis sich C++ auf µCs durchgesetzt hat bist Du mit C als C++ Subset gut bedient ;-)
cppler schrieb: > Wobei C++ mehr Möglichkeiten bietet als Object-PASCAL ! > Aber bis sich C++ auf µCs durchgesetzt hat bist Du mit C als C++ Subset > gut bedient ;-) Dem muss ich widersprechen, C++ bietet mit nichten mehr Möglichkeiten wie Objective-Pascal. Nur, ist die Wahl der Programmiersprache ein müssiges Thema. Die Programmiersprache ist lediglich ein Werkzeug welches für den Zweck optimal ausgewählt werden sollte. Grüsse, R.
Rene H. schrieb: > cppler schrieb: > > Dem muss ich widersprechen, C++ bietet mit nichten mehr Möglichkeiten > wie Objective-Pascal. > Jein, man kann z.B. Templates in Object-PASCAL nachbilden aber es ist nicht so einfach wie in C++ genau wie die Kapselung ansich. Von den aktuellen Bibliotheken mal abgesehen, aber das hat nichts mehr mit µC zu tun ;-) EIFFEL hat sich ja auch nicht durchgesetzt obwohl da noch "bessere" Möglichkeiten implementiert sind als in PASCAL oder C++ ! PASCAL ist ja auch nicht wegen Wirth so populär geworden, sondern wegen der Funktionalität von TurboPASCAL, lag also weniger an der Sprache sondern den Bibliotheken dafür. Modulo hat's ja auch nicht geschafft aber C/C++ wird's noch länger geben. Nicht ideal weiß ich, aber besser als BASIC :-P
g. c. schrieb: > 5-Sterne-Los schrieb: >> Für C spricht, dass Pascal nie über den Status einer akademischen >> Sprache hinaus kam. Sehr gut für die Lehre (zumindest vor ca. 20 >> Jahren), aber ohne Praxisrelevanz. > > Aber Delphi/Lazarus ist alles andere als eine rein akademische Sprache. > Sonst gäbe es wohl kaum solche Software hier: Ja, es gibt auch kommerzielle Software, die in Prolog geschrieben wurde.
Karl Heinz Buchegger schrieb: Sonst gäbe es wohl kaum solche Software hier: > > Ja, es gibt auch kommerzielle Software, die in Prolog geschrieben wurde. Genau und es gibt eine Programmiersprache die wirklich mathematisch bewiesen wurde, wer benutzt die nun deswegen ? Und COBOL ist gerade wieder voll im kommen, natürlich nur wegen der Vorteile von COBOL gegenüber C++ und Konsorten :-P Könnte man ja auch in C abbilden GOTO und so :-P
Karl Heinz Buchegger schrieb: > g. c. schrieb: >> 5-Sterne-Los schrieb: >>> Für C spricht, dass Pascal nie über den Status einer akademischen >>> Sprache hinaus kam. Sehr gut für die Lehre (zumindest vor ca. 20 >>> Jahren), aber ohne Praxisrelevanz. >> >> Aber Delphi/Lazarus ist alles andere als eine rein akademische Sprache. >> Sonst gäbe es wohl kaum solche Software hier: > > Ja, es gibt auch kommerzielle Software, die in Prolog geschrieben wurde. Nur verstehe ich deinen Einwand (sollte wohl einer sein oder?) jetzt nicht. Es gibt nun mal eine allgemeine Beliebtheit bestimmter Programmiersprachen. Dazu kann man jetzt bekannte Indexe befragen oder einfach mal hier im Forum sich ein bisschen umhören bzw. Postings lesen, gewissermaßen als Stichprobe der Grundgesamtheit. Da wird man dann weit überwiegend C, C++, C#, Pascal, Java und verschiedene Skriptsprachen finden. Das ganze hat auch sehr stark damit zu tun, wie sich die ein- oder andere Sprache dazu eignet Windows-Programme (also GUI-Programme) oder Plattform übergreifende Linux<->Windows -Programme (Mac oder andere eher selten) zu erstellen. Hierfür sind die Klassenbibliotheken oder "Widget Toolkits" als Erweiterungen von Delphi (VCL), Lazarus (gleich mehrere wie QT, GTK+, GTK2 ...), Visual Studio C/C++/C# (MFC, .NET (Forms oder WPF)), oder freie C++ IDEs, die beispielsweise wxWidget einbinden maßgeblich. Da gibt es verschiedenste Tools bzw. Kombinationen, die mehr oder weniger komfortabel einzurichten sind. Nur taucht da i.d.R. kaum "Prolog" bei auf. Ich glaube also nicht, dass man "Prolog" da mit einreihen kann. Ebenso wenig wie ADA, Brainf*ck, Haskell oder was es alles noch so gibt. Objective C wäre vielleicht noch zu den Platzhirschen zu zählen und vielleicht auch good old Assembler, wegen seiner großen Fangemeinde, auch wenn es praktisch immer mehr durch C verdrängt wird (so mein Eindruck). Im Grunde haben doch Borland mit Turbo Pascal, Turbo C(++) und MS mit den Visual Studio Produkten hier die Vorlieben vieler damals entscheident beeinflusst und das hält bis heute an, wenn auch mit verlagerten Gewichten, weil gewisse Firmen es einfach nicht gebacken bekommen, den MS Express-Produkten etwas gleichwertiges (kommerziell-lizenziertes) entgegenzusetzen, ohne dafür einen Obolus seiner Fangemeinde abzupressen. Embarcadero hätte es in der Hand sich ein Stück vom Markt zurückzuerobern. Aber nur allein über die Geldschiene wird das nicht gelingen. Dazu sind die kostenfreien Alternativen zu mächtig geworden. PS: Brainf*ck kann man hier nicht mal schreiben, ohne dass die Forensoftware Spammalarm schlägt. Irgendwie passend. ;)
Rene H. schrieb: > Die Programmiersprache ist lediglich ein Werkzeug Nein. Software ist ein lebendes Objekt, das sich ständig gewartet wird, sich anpassen muß, von sich ständig ändernden Gruppen bearbeitet wird. Wenn Du die Analogie zum Handwerk bemühen willst, paßt ein Vergleich der Sprache mit dem Material besser. Du wirst ein Bücherregal aus Holz schneller und leichter an bauliche Gegebenheiten anpassen können als eins aus Stahl oder gar Glas, eben so sinkt die Zahl derer, die solche Anpassungen vornehmen können. Du wirst für ein Holzregal deulich mehr Beschläge und Schrauben finden als für Stahl oder gar Glas, von den Möglichkeiten der Oberflächengestaltung mal ganz abgesehen. Das Pascal oder Basic üblicherweise nur ein kurzes Lachen auslösen, hat nichts mit Arroganz zu tun - es ist einfach angebracht. Wie schon andernorts erwähnt, wenn man keinerlei Interaktion mit der Restwelt beabsichtigt, kann man problemlos in irgendwas Programmieren. Andernfalls eben nicht. BTW: Ich liebe Delphi. Nützt nur nix.
Dauergast schrieb: > Software ist ein lebendes Objekt, das sich ständig gewartet wird, sich > anpassen muß, von sich ständig ändernden Gruppen bearbeitet wird. Das gilt auch für so manchen Blumengarten und trotzdem sind Rechen und Hacke mur Werkzeuge...
Omg. Ich dachte, diese "meine Sprache ist die Tollste" Diskussionen sind endlich mal vorbei :/ Karl Heinz Buchegger schrieb: > Ja, es gibt auch kommerzielle Software, die in Prolog geschrieben wurde. Wird Gründe haben. Versuch doch mal ernsthaft einen High-performance backward-chainer zu schreiben^^. Warrens Artikel zu diesem Thema kann ja wirklich keiner lesen ;-) Und btw.: Der Observation scheduler des Hubble Teleskops ist übrigens in Lisp geschrieben, wie viel anderes Zeug auch. Auch Fortran erfreut sich immer noch groser Beliebtheit. Gibt vielleicht doch etwas mehr Anwendungen, die wir hier nicht wirklich durchblicken ? Die Leute, die sowas SO programmieren, wie sie es machen, sind ja auch nicht gegen den Schrank gelaufen^^ cppler schrieb: > Und COBOL ist gerade wieder voll im kommen Ehr nicht, aber ziemlich stabil im Markt, z.B. bei Banken. Die würden ja gerne umsteigen aber keine SW Bude traut sich, für ihre Neuimplementierung die Hand ins Feuer zu legen. Pro Tag werden über Forex ~4000 Mrd/Tag (! kein Witz) gehandelt. Wenn Du da dann für, z.B. durch Rundungsfehler entstandene, Schäden haften willst .... Karl Heinz Buchegger schrieb: > Code ist nur eine > konkrete Umsetzung von Algorithmen und lässt sich in jeder beliebigen > Sprache aus demselben Paradigmenbereich in kurzer Zeit neu schreiben. Da hast Du prinzipiell recht. Aber Pascal kann z.B. verschachtelte Prozedurdefinition. Das heisst insbesondere aber auch, dass eine lokale Variable einer Prozedur eine globale Variable einer in diesem Scope definierten Prozedur ist. Davon hast Du dann u.U. eine ganze Menge und nun viel Spass beim Umsetzen. Geht aber nervt. Grüße Andreas
Andreas schrieb: >Wenn Du da dann für, z.B. durch Rundungsfehler entstandene, Schäden haften >willst .... Dann wirst Du vorher vom Auftraggeber rund gemacht. ;-) MfG Paul
Reinhard Kern schrieb: > Rainer S. schrieb: >> Die Quellen gebe ich >> üblicherweise nicht heraus. > > Mit anderen Worten, alle deine Software stirbt mit dir und die Kunden > stehen mit ihrer Fehlinvestition im Regen. Da hast du natürlich recht, > wenn man die Leute so über den Tisch zieht, kommt es auf C oder Pascal > auch nicht mehr an. Ich dachte, du wärst ein seriöser Geschäftspartner. > > Gruss Reinhard Sag mal, findest Du das nicht reichlich frech was Du hier so von Dir gibst? Ich habe Dir eine Alternative zu Deinem Delphi genannt, wo Du Dich schon ganz erheblich vergallopiert hast. Darauf gehst Du nicht ein. Die Software läuft weiter. Auch wenn kein Quellcode mehr da sein sollte. Oben steht das Wort 'üblicherweise'. Außerdem kennst Du meine Firmenstruktur nicht. Und weiter ist es in weiten Teilen üblich, dass man die Quellen nicht herausgibt. Schon mal davon gehört? Ich denke, wenn Du noch nicht mal auf das eingehst was man Dir praktisch vor der Nase hält ist das mit Deinen softwaretechnischen Leistungen nicht weit her. Dauergast schrieb: > Das Pascal oder Basic üblicherweise nur ein kurzes Lachen auslösen, hat > nichts mit Arroganz zu tun - es ist einfach angebracht. Wie schon > andernorts erwähnt, wenn man keinerlei Interaktion mit der Restwelt > beabsichtigt, kann man problemlos in irgendwas Programmieren. > Andernfalls eben nicht. > > BTW: Ich liebe Delphi. Nützt nur nix. Es mag sein, dass die ehemals Delphi und jetzt Freepascal Programmierer prozentual vielleicht im einstelligen Bereich sind. Sie sind aber ganz sicher nicht 'vom Rest der Welt' abgeschnitten. Ich hoffe noch auf einen Compiler, der Pascal und C kann. Vielleicht kann Freepascal das irgendwann (zumindest die Header Dateien, z.B. die von den STM32 ARM Controllern). Ebenfalls ist die Firma Mikroelektronika, die C, Basic und Pascalcompiler im Angebot haben nicht vom Rest der Welt abgeschnitten, ganz im Gegenteil. http://www.mikroe.com/news/view/577/mikroelektronika-s-ceo-pronounced-entrepreneur-of-the-year-2012-in-our-home-country
Rainer S. schrieb: > Ich überlege jetzt evtl. auf C umzusteigen bevor es "zu spät" ist. Im embedded Bereich ist alles was ich gesehen habe in C (oder Assembler). Alle libs, app-note Bespiele, Compiler der Hersteller etc pp. Welche Sprache die tollere ist spielt doch wohl keine Rolle, jede hat ihre Macken (und auch jeder compiler). Auf irgendwas musste man sich halt einigen, durchgesetzt hat sich eben C. Nicht ohne Grund, C macht auf µC's Sinn da es eine Sprache ist die für Betriebssysteme designt wurde. Nichts anderes macht man auf einem µC ohne OS, man schreibt ein OS. Zweiter Grund C ist per design "portabel" (was immer man davon halten mag). Das kommt einem zu Gute wenn man von einem Controller auf einen anderen umschreibt (auch und gerade innerhalb der selben Herstellermarke) oder wenn man 3rd Party code verwendet. Das ist ständig der Fall, es sei denn man will jeden USB Stack und jede SD-Card Anbindung unbedingt selbst schreiben.
Dauergast schrieb: > BTW: Ich liebe Delphi. Nützt nur nix. Die Frage ist nur: Liebt dein Delphi auch dich?
Andreas H. schrieb: > Omg. Ich dachte, diese "meine Sprache ist die Tollste" Diskussionen sind > endlich mal vorbei :/ > > Karl Heinz Buchegger schrieb: >> Ja, es gibt auch kommerzielle Software, die in Prolog geschrieben wurde. > > Wird Gründe haben. Versuch doch mal ernsthaft einen High-performance > backward-chainer zu schreiben^^. Warrens Artikel zu diesem Thema kann ja > wirklich keiner lesen ;-) > > Und btw.: Der Observation scheduler des Hubble Teleskops ist übrigens in > Lisp geschrieben, wie viel anderes Zeug auch. Auch Fortran erfreut sich > immer noch groser Beliebtheit. > > Gibt vielleicht doch etwas mehr Anwendungen, die wir hier nicht wirklich > durchblicken ? > Die Leute, die sowas SO programmieren, wie sie es machen, sind ja auch > nicht gegen den Schrank gelaufen^^ Natürlich nicht. Das wollte ich damit auch nicht sagen. Nur werde ich im Umkreis von 200 Kilometer um meinen Standort eher kaum einen potentiellen Auftraggeber finden, der sich auf Cobol, Fortran oder Prolog versteift. Und diejenigen, die solche Aufträge haben, ... an die kommst du als Neuling nicht oder nur sehr schwer ran. Da sitzen die Stammprogrammierer drauf, wie die Hennen auf den Eiern. PS: Mein erster Industriejob war in Fortran. Das war allerdings 1988 und die PC-Szene steckte damals noch in den Kinderschuhen. Wenns damals nach mir gegangen wäre, wäre sie dort auch geblieben. Mir war die VAX lieber. Aber hilft ja nichts. Wenn du 2 Jobs auf einer VAX angeboten kriegst und 30 auf einem PC, dann muss man auch mal über seinen Schatten springen und die Zeichen der Zeit erkennen. > Omg. Ich dachte, diese "meine Sprache ist die Tollste" Diskussionen sind > endlich mal vorbei :/ Daraus will ich mich eigentlich auch raushalten. Zum einen, weil ich sie nicht für zielführend halte, zum anderen weil sie einfach Unsinn ist. Wer seine Sprache beherrscht, für den stellt sich die Frage nicht. Allerdings finde ich die Ausgangsfrage nicht fair. Ich kann nicht auf der einen Seite fragen, ob man von Pascal auf C wechseln soll und auf der anderen Seite dann alles mit dem Argument beiseite wischen, dass man ja so eine große Codebasis hätte, die man nicht verwerfen will. Denn was anderes kommt da eh nicht raus. Auch C ist kein Wunderwuzzi, mit dem alles automatisch gehen würde, was man in Pascal ausprogrammieren muss. Da muss ich mich fragen: Mit welcher Erwartungshaltung geht der Fragesteller an die Frage heran? Was verspricht er sich von einem Wechsel? > Was spricht für C? Die einzige vernünftige Antwort, die mir darauf einfällt ist: Technisch nichts bzw. nicht viel. Praktisch hast du in C sehr wahrscheinlich eine größere Community in diversen Newsgroups, Foren und Blogs. Und eine größere Nachfrage am Arbeitsmarkt.
Ich hatte mal an der Uni mit Pascal angefangen. Irgendwann auch C. Es ist erheblich weniger Tipparbeit, ich halte den Code auch für klarer und besser lesbar. Nebenbei gibt es für jeden Feld-, Wald- und Wiesenmaschine einen C-Compiler. Ich mag C ;)
Karl Heinz Buchegger schrieb: > Allerdings finde ich die Ausgangsfrage nicht fair. Ich kann nicht auf > der einen Seite fragen, ob man von Pascal auf C wechseln soll und auf > der anderen Seite dann alles mit dem Argument beiseite wischen, dass man > ja so eine große Codebasis hätte, die man nicht verwerfen will. Denn was > anderes kommt da eh nicht raus. Auch C ist kein Wunderwuzzi, mit dem > alles automatisch gehen würde, was man in Pascal ausprogrammieren muss. > Da muss ich mich fragen: Mit welcher Erwartungshaltung geht der > Fragesteller an die Frage heran? Was verspricht er sich von einem > Wechsel? Die große Codebasis ist ein PC Programm, das bleibt wohl auch in Pascal. Die Mikrocontroller haben eine eher vergleichsweise kleine Codebasis. Ich habe die AVR's bis vor Kurzem zu 100% in Assembler programmiert. Mit dem beigelieferten Assembler von Atmel. Vorher habe ich 8051 Prozessoren in Assembler programmiert. Die AVR Assemblerprogramme nach Pascal zu migrieren dauert einige Tage/Wochen. Der Pascalcompiler von Mikroelektronia arbeitet voll zufriedenstellend und ist einfach in der Handhabung. Ein Umstieg der fertigen AVR Pascalprogramme nach C würde vermutlich schneller gehen. Der Hauptknackpunkt sind halt die Headerdateien für die sehr umfangreichen STM32 (und andere) ARM Controller. Langfristig ist ein Umstieg auf ARM sicher der sinnvollste Weg. Deswegen kam die Frage auf. Mikroelektronika hat hier Pascal-konforme Bibliotheken. Allerdings sind diese wohl nur in Binärform vorhanden, aber immerhin. Ein Aspekt, der hier bei der Diskussion für mich neu aufgekommen ist, aber der für mich wohl nicht relevant ist, ist die größere Nachfrage am Arbeitsmarkt. Ich hatte nicht unbedingt vor, als Sub Unternehmer für eine andere Firma zu arbeiten.
Rainer S. schrieb: > Ich denke, wenn Du noch nicht mal auf das eingehst was man Dir praktisch > vor der Nase hält ist das mit Deinen softwaretechnischen Leistungen > nicht weit her. Aber wenn du genauso verfährst, ist das in Ordnung, was? > Ich hoffe noch auf einen Compiler, der Pascal und C kann. Au weia...
Karl Heinz Buchegger schrieb: >> Omg. Ich dachte, diese "meine Sprache ist die Tollste" Diskussionen sind >> endlich mal vorbei :/ > > Daraus will ich mich eigentlich auch raushalten. > Zum einen, weil ich sie nicht für zielführend halte, zum anderen weil > sie einfach Unsinn ist. Wer seine Sprache beherrscht, für den stellt > sich die Frage nicht. Ich sehe schon, wir sind einer Meinung :-) > Mir war die VAX lieber Mir auch ;-) Grüße Andreas
Rainer S. schrieb: > Und weiter ist es in weiten Teilen üblich, dass > man die Quellen nicht herausgibt. > > Schon mal davon gehört? Ja, von Kunden die mit so etwas schon mal erheblich hereingefallen sind, teilweise mit verlorenen Investionen im Hunderttausender-Bereich. Die machen den Fehler, sich dagegen nicht abzusichern, aber nur einmal, beim nächsten Projekt fragen sie sehr wohl was aus der Software werden soll, wenn der Programmierer stirbt überlastet ist in Insolvenz geht / grössenwahnsinnig wird oder auch einfach keine Lust mehr hat. Und dabei spielt eben auch eine Rolle, in welcher Sprache die Software erstellt wurde. Rainer S. schrieb: > Die Software läuft weiter. Auch wenn kein Quellcode mehr da sein sollte. Diese Antwort auf das Problem ist einfach nur eine Frechheit, und zudem beweist sie weitgehende Unkenntnis, denn es gibt Tausende alte Programme, die aus verschiedensten Gründen unter Windows 7 oder 8 nicht mehr laufen. Wenn du deine Kunden so behandeln kannst, deine Sache. Ich arbeite eher für internationale Konzerne, das ist eine andere Welt. Z.B. deswegen, weil die eine Rechtsabteilung mit unbegrenzten Resourcen zum Einsatz bringen können. Karl Heinz Buchegger schrieb: > Die einzige vernünftige Antwort, die mir darauf einfällt ist: > Technisch nichts bzw. nicht viel. Das ist aber zugleich die Antwort darauf, warum soviel C in der Welt ist: C ist so einfach strukturiert, dass es für einen Hersteller eines Prozessors mit Abstand am einfachsten ist, einen C-Compiler dafür zu erstellen. Gruss Reinhard
Mike Krüger schrieb: > Liebt dein Delphi auch dich? Es tut im Prinzip alles, was ich will, wie ich es will, ohne jegliche Zickerei - ob man das Liebe nennen kann oder sollte, weiß ich nicht ;-) Wenn allerdings eine Developer Preview irgendeines OS, eine neue Hardware oder eine neues Protokoll irgendwo auftaucht, gibt es C-Header, C-Objects bzw. C-Libs, manchmal C-Source ... und ganz sicher nichts, mit dem Delphi was anfangen könnte. Ähnlich verhält es sich auf µCs.
Ich hab aufm PC immer mit Delphi gearbeitet, und auf Embedded auch mit einem Pascal. Es ist einfach besser selbstdokumentiert. Ich kann den Code auch nach 10 Jahren noch schneller lesen und verstehen. Bisher hatte ich noch nirgends, aeh keiner Firma, Probleme mit Pascal. Denn meine Leistung ist nicht Code, sondern ein geloestes Problem. Und wenn das Problem geloest ist .. Deckel drauf und Next. Falls denn irgendwann mal ein Nachfolger den Code anschauen sollte, ist er leichter verstaendlich wie ein C. Ist eben so. Und da dann die Bedingungen drum herum eh sehr anders sind, muss man's eh neu schreiben. Ich sag mir .. das Leben ist viel zu kurz fuer C.
Joe G. schrieb: > etwas Öl ins Feuer... > > http://www.bernd-leitenberger.de/pascal-und-c.shtml Na ja. Jeder der C einigermassen kennt, sieht da aber recht schnell, dass Bernd von C nicht wirklich Ahnung hat, sondern hauptsächlich rummosert. Und das zum Teil falsch und zum Teil mit falschen Argumenten. Dieses Pamphlet kann man nicht wirklich ernst nehmen. Was nicht heissen soll, dass man an C keine Kritik üben kann/darf. Überhaupt nicht. Es gibt genug Kritikpunkte und einige davon spricht Bernd sogar an (zb enum). Dafür haut er an anderen Stellen wieder dermassen daneben. Ist ungefähr so, wie wenn ich Prolog kommentieren müsste. Ein bißchen Prolog kann ich, aber für eine ernsthafte Kritik reicht es bei weitem nicht.
Reinhard Kern schrieb: > Rainer S. schrieb: >> Und weiter ist es in weiten Teilen üblich, dass man die Quellen nicht >> herausgibt. Schon mal davon gehört? > Ja, von Kunden die mit so etwas schon mal erheblich hereingefallen sind, > teilweise mit verlorenen Investionen im Hunderttausender-Bereich. […] Ich verstehe nicht ganz, warum du Rainer (sogar wiederholt) so heftig angreifst, nur weil er nicht den Quellcode seiner Software herausrückt. Das tun doch die allerwenigsten Softwarefirmen. Oder bekommst du als Käufer von MS-Word, Eagle, Oracle oder SAP etwa immer schön brav den Quellcode mitgeliefert? Ich würde das zwar auch gbegrüßen, kann aber auch verstehen, dass die Firmen mit Closed-Sorce ihre Entwicklungsaufwendungen schützen wollen. Eine Ausnahme bilden Auftragsentwickler, die kundenspezifische Software entwicklen und vom Kunden nicht für das Produkt, sondern die Entwicklungsarbeit bezahlt werden. Da ist es üblich, auch den Quellcode auszuliefern, sofern der Kunde das möchte. Aber zu den Auftragsentwicklern gehört Rainer wohl eher nicht: Rainer S. schrieb: > Ich hatte nicht unbedingt vor, als Sub Unternehmer für eine andere Firma > zu arbeiten.
cppler schrieb: > PASCAL ist ja auch nicht wegen Wirth so populär geworden, sondern wegen > der Funktionalität von TurboPASCAL, lag also weniger an der Sprache > sondern den Bibliotheken dafür. Da muss ich wiedersprechen, Borland hat damals mit dem TurboPascal die Sprache erweitert, weil Pascal eben nicht wie C durch Bibliotheken erweiterbar ist. In Wirths Pascal kannst du z.B. keine Tasten abfragen, weil alle Eingaben mit CR abgeschlossen sein müssen. Um die Pfeiltasten an einem VT100 damals zu benutzen musste ich auf der VAX ein Fortran Programm für die Tasten Abfrage dazu linken ;) Und die Strings nannte man auch damals noch varying char of. Und Pascal war nicht Pascal, das Umschreiben eines HP Pascal Programmes in ein DEC Pascal war nicht trivial ;) Mit Turbo Pascal konnte man wirklich arbeiten aber das gabs damals nur auf PC's unter Dos. Leider hat Borland dann weitergemacht und viel zu viel an der Sprache weiter herumgebastelt und alles ist nicht genormt, deshalb bin ich schon sehr früh auf C umgestiegen und geblieben.
Rainer S. schrieb: > Ich hoffe noch auf einen Compiler, der Pascal und C kann. Der nennt sich C-Compiler .. Einfach mit einem Makro {} durch Begin End ersetzen ... Alles schon gesehen ...
Dauergast schrieb: > BTW: Ich liebe Delphi. Nützt nur nix. Mike Krüger schrieb: > Liebt dein Delphi auch dich? National Instruments liebt Delphi jedenfalls nicht ;)
Rainer S. schrieb: > Und weiter ist es in weiten Teilen üblich, dass > man die Quellen nicht herausgibt. > > Schon mal davon gehört? Ich sag immer: Wenn die Konkurrenz die Quelltexte in die Hand bekommt, das wirft die um Jahre zurück
Christian Berger schrieb: > Also wenn Du GUI machst, kommst Du im Moment fast nicht um Lazarus rum. > (Pascal basierend) > > C erfordert eine gewisse Erfahrung und Disziplin, das sollte man erst > nach einem Assembler machen. C++ ist eher was für Masochisten, die eine > Sprache andauernd lernen wollen, und denen gutes Sprachdesign egal ist. Wer Softwareentwicklung macht, muss andauernd lernen. Die Sprache ist da mittlerweile das kleinere "Übel". Auch wenn ich C++ nicht für die "beste" Sprache halte, es ist imo besser als viele Alternativen. BTW: Sowohl Pascal, als auch C und C++ sind nicht typsicher. > C# ist halt wie VBA eine reine Microsoftsache und selbst für > nur-Windows-Projekte eine eher schlechte Wahl. C# und VBA haben als Gemeinsamkeit nur die Herkunft. Rein Microsoft ist da schon lange nichts mehr (ISO/ECMA-Standard, Mono, Xamarin (Android, Mac/iOS) etc.). Die einzigen Gründe (für einen Teil eines Projektes) was anderes als C# zu nehmen sind heutzutage nur noch, wenn die maximale Geschwindigkeit herausgeholt werden soll, dann C bzw. C++ oder wenn das Projekt mit einer anderen Sprache begonnen wurde und eine Neuentwicklung zu aufwendig wäre. > Wenn Du C machen willst, lies Dir erst mal "The Art of UNIX Programming" > durch. http://www.faqs.org/docs/artu/ > Das Buch stellt ein Regelwerk vor, dass Dir für C und andere Sprachen > helfen kann. Das hilft Dir dabei bessere Softwaresysteme zu entwickeln. Gerade das Buch würde ich keinem empfehlen, da der Autor mindestens genauso ideologisch verblendet "argumentiert" wie rms.
Ich habe auch mit Turbo Pascal angefangen - auf CP/M und später dann DOS. Dann kam der Amiga, und da gab es 1987 kein Pascal, sondern nur C, und die gesamte Dokumentation war für Assembler und Lattice C, und so habe ich dann C gelernt und es nie bereut. Auf dem PC wurden Windows und OS/2 langsam reif, und auch das war eben C. Irgendwann war Pascal für mich einfach gestorben. Ich finde den Support des jeweiligen Herstellers sehr wichtig. Wenn STM Keil, IAR und gcc unterstützen, dann werde ich wenn möglich einen der empfohlenen Compiler verwenden, einfach um Risiken zu vermeiden und Zeit zu sparen. Wenn Microchip seine Application Libraries nur für die hauseigenen Compiler anbietet, dann werde ich einen Teufel tun und den Mikroe Compiler verwenden. Wenn dann nämlich irgendwo ein Bug auftritt (der kann in der Software oder im Silizium sein), dann will ich meinen FAE oder Microchip anpieksen und fragen können, was das soll, und das kann ich nur, wenn ich einen der getesteten Compiler verwende. Nur dann können die das auch nachvollziehen und mir ggf bestätigen, dass ich einen Bug im Silizium gefunden habe, und wie ich den umgehe. Alles schon passiert. Die Programmiersprache ist nur ein Werkzeug. Mit Pascal kann ich genauso leben wie mit Occam (kennt das noch jemand?). Und ob die Entwicklungsumgebung nun unter Linux läuft, ist mir sowas von egal. Meist ist das ganze unter Windows am Besten getestet, und dann nehme ich Windows. Zum OP: Es ist für Dich vielleicht gar nicht schlecht, aus Deiner "Komfortzone" herauszukommen und Dich auf etwas neues einzulassen. Flexibel bleiben heißt das Zauberwort. fchk
Reinhard Kern schrieb: > Rainer S. schrieb: >> Und weiter ist es in weiten Teilen üblich, dass >> man die Quellen nicht herausgibt. >> >> Schon mal davon gehört? > > Ja, von Kunden die mit so etwas schon mal erheblich hereingefallen sind, > teilweise mit verlorenen Investionen im Hunderttausender-Bereich. Die > machen den Fehler, sich dagegen nicht abzusichern, aber nur einmal, beim > nächsten Projekt fragen sie sehr wohl was aus der Software werden soll, > wenn der Programmierer stirbt überlastet ist in Insolvenz geht / > grössenwahnsinnig wird oder auch einfach keine Lust mehr hat. Was da genau passiert ist schreibst Du leider nicht dabei. Insofern kann man nur spekulieren. > Rainer S. schrieb: >> Die Software läuft weiter. Auch wenn kein Quellcode mehr da sein sollte. > > Diese Antwort auf das Problem ist einfach nur eine Frechheit, und zudem > beweist sie weitgehende Unkenntnis, denn es gibt Tausende alte > Programme, die aus verschiedensten Gründen unter Windows 7 oder 8 nicht > mehr laufen. Wenn du deine Kunden so behandeln kannst, deine Sache. Ich > arbeite eher für internationale Konzerne, das ist eine andere Welt. Und dann bist Du überfordert, wenn Embarcadero ein paar Tausend Euro haben will? Beitrag "Re: C oder Pascal" Oder ist das wieder eine andere Welt? Für Windows programmiere ich schon lange nicht mehr. Mich zwingt auch kein Auftraggeber - aus einer anderen Welt - dazu. > Z.B. > deswegen, weil die eine Rechtsabteilung mit unbegrenzten Resourcen zum > Einsatz bringen können. Dann sollte es ja kein Problem sein, an den Quellcode des Entwicklers zu kommen. Für entsprechndes Geld wäre ich natürlich auch bereit das zu liefern. Mir hat mal ein Kunde angeboten eine entsprechende Vereinbarung zu unterschreiben bei 100.000 Euro Strafe, wenn er die Sachen weitergeben sollte. Der Kaufpreis war erheblich geringer. Habe das abgelehnt. Habe dann mit einem Bekannten darüber gesprochen. Er meinte dann der Quellcode könnte ja auch z.B. vom Kunden durch irgendwen geklaut werden... Hans-Georg Lehnard schrieb: > Einfach mit einem Makro {} durch Begin End ersetzen ... Wenn das so einfach wäre... ah. schrieb: > Es ist einfach besser selbstdokumentiert. Ich kann den > Code auch nach 10 Jahren noch schneller lesen und verstehen. Ja, genauso. Und wenn man C Quelltexte lesen muss tun einem schon mal die Augen weh. :-) Das ist zwar durch die { } Teile hochkomprimiert dargestellt. Dadurch muss man aber auch mehr Informationen verarbeiten. Yalu X. schrieb: > Ich verstehe nicht ganz, warum du Rainer (sogar wiederholt) so heftig > angreifst, nur weil er nicht den Quellcode seiner Software herausrückt. Verstehe ich jetzt auch nicht so ganz.
Yalu X. schrieb: > Oder bekommst du als > Käufer von MS-Word, Eagle, Oracle oder SAP etwa immer schön brav den > Quellcode mitgeliefert? Das ist eine unsinnige Argumentation, denen habe ich ja auch keinen Entwicklungsauftrag erteilt. Ich kenne aber einige Leute, die Software-Aufträge von 20 kEuro aufwärts vergeben hatten und dann mit einer nur so halbwegs funktionierenden Beta-Software und ohne jegliche Unterlagen einfach sitzengelassen wurden. Es ist sogar schon vorgekommen, dass man mir den Auftrag gern noch mal erteilt hätte, aber der gesamte Entwicklungsetat war schon weg für nichts und einfach nicht mehr genug Geld da. Wenn man was auf eigenes Risiko und mit eigenem Geld entwickelt, ist das was anderes. Aber Autragsentwicklung von Software ist keineswegs bloss eine Ausnahme, längst nicht jede Firma, die ein Gerät entwickelt, hat auch eine eigene Softwareabteilung. Gruss Reinhard
Hans-Georg Lehnard schrieb: > National Instruments liebt Delphi jedenfalls nicht ;) Ich hab LabView im Kundenauftrag auch schon mal F90 fressen lassen. Ging sogar ziemlich unblutig^^ Grüße Andreas
Frank K. schrieb: > Zum OP: Es ist für Dich vielleicht gar nicht schlecht, aus Deiner > "Komfortzone" herauszukommen und Dich auf etwas neues einzulassen. > Flexibel bleiben heißt das Zauberwort. Ich habe schon mal in C++ programmiert. Auf der embeddedWorld in Nürnberg habe ich Mikroe besucht und die Leute haben mich stark beeindruckt. Den Support sehe ich zur Zeit gegeben. Wenn das mal irgendwann nicht mehr sein sollte gibt es vielleicht Alternativen, die momentan noch nicht reif sind. Wie gesagt, das beste wäre ein C++ und Pascal Compiler in einem. Damit könnte ich leben :-) Reinhard Kern schrieb: > Es ist sogar schon > vorgekommen, dass man mir den Auftrag gern noch mal erteilt hätte, aber > der gesamte Entwicklungsetat war schon weg für nichts und einfach nicht > mehr genug Geld da. Da hab' ich aber jetzt nix mit zu tun. Ich kenne es eher anders herum. Die Kunden wollen nicht genug zahlen. Bzw. man muss den Preis so attraktiv machen, dass die Kunden kaufen. Und dann soll ich auch noch den Quellcode herausrücken? Außerdem interessieren sich nur die wenigsten dafür, geschweige denn dass die wissen was ein Quellcode ist.
Reinhard Kern schrieb: > längst nicht jede Firma, die ein Gerät entwickelt, hat > auch eine eigene Softwareabteilung. Es ist leider noch viel schlimmer. Manche Firma HAT eine eigene Softwareabteilung. Leider ist da auch öfter die Qualität unterirdisch. Es reicht eben nicht im Studium einmal eine 1-Semester Kurs zu machen und dann Applications für Endkunden zu entwickeln. Aber, sieh es positiv. Das sind alles potentielle Kunden für Dich ;-) Grüße Andreas
Mit dem Support ist nicht der von Mikroe zu ihrem Compiler gemeint, sondern dass die Chip-Hersteller die Hardaware und den Compiler supporten. Im Fehlerfall kann das Tage an debugging sparen, weil der Hersteller sich drum kümmert. Der wird sich aber nicht drum scheren, wenn du irgend einen Compiler verwendest, kann ja schliesslich an diesem Compiler liegen. Und m.M.n sind Compiler die vom Hersteller gewartet werden sowie OpenSource Lösungen deutlich im Vorteil gegenüber einem Compiler einen kleinen Firma, die in den nächsten paar Tagen dicht machen könnte oder gar nicht die kapazitäten hat sich zeitnah um die Probleme zu kümmern.
SAP liefert schon immer Quelltext aus. Früher (R/2) wurden die Assemblerquellen erst auf den Kundenrechnern übersetzt, ganz so wie man es heute von UNIX OSS Paketen kennt. Heute gibt's die gesamte ABAP Source der Anwendungen, die dann bei erster Benutzung in "ByteCode" übersetzt werden. Nur der C(++)-Kernel (inkl. VM) kommt ohne Source. Soviel zum Gerücht von Xalu X.
ABAP schrieb: > Nur der C(++)-Kernel (inkl. VM) kommt ohne Source. Eben. Und was heißt da "nur"? Der Kernel ist, wie der Name schon sagt, die zentrale Komponente des Systems, ohne die die ganzen ABAP-Module wertlos sind, selbst wenn sie im Quellcode vorliegen.
Ich denke ihr redet aneinander vorbei, abgesehen das es nichts zum Thema beiträgt. Bei einer Auftragsenwicklung gehört der Code bei, inkl. UML und ordentlicher Dokumentation. Punkt. Da gibts nichts zu ändern. Bei einer Eigenentwicklung kann man, muss man nicht. Ich habe viele Sourcen öffentlich freigegeben, nur diejenigen welche mein Geschäft ausmachten nicht. Grüsse, R.
Joe G. schrieb: > etwas Öl ins Feuer... > > http://www.bernd-leitenberger.de/pascal-und-c.shtml Mh... Bei der Verwendung von Inkrementierung und Dekrementierung ist sogar ein Fehler drin :P > int x; > x=5; > --x=(++x)--; > > Nein, das Ergebnis ist nicht 4 sondern 6. Ich musste selbst erst nachdenken, kam aber ebenfalls auf 4 und mein VS 2010 gab mir Recht. Niemand wird gezwungen so einen Müll zu programmieren. Ja es geht - na und? In Cpp geht auch 10fach-Vererbung - trotzdem macht das wahrscheinlich kaum einer, weil es sehr hässlich werden KANN. Ich weiß nicht, ob jemand von euch mal in den Geschmack von Oberon gekommen ist. Ich fand diese Sprache (auch von Niclaus Wirth) schrecklich. Man macht dank ALLER UPPERCASE OPERATOREN seine shift-Taste kaputt. Dummerweise waren trotzdem nicht alle Befehle Upercase sodass das alles sehr merkwürdig war. Und ja, ich habe Programmieren auch mal in Pascal gelernt - trotzdem gibt es schönere Sprachen und ich könnte heute nicht mehr auf Pascal zurück. Aber ich sehe das auch etwas pragmatischer: wenn man einmal über 10 - 15 Sprachen ausprobiert hat, wird man sich wahrscheinlich diejenige aussuchen, die für das entsprechende Problem passt... z.B. C/Cpp für muC (weil es schnell ist und an sich gut geht), C# für Windoofs-Sachen (weil die GUIs gut gehen und die Software gut wartbar ist), Autohotkey für Hack-Gefrickel/Scripting-Kram (weil es einfach ist und damit Simulation von Benutzereingaben gut gehen - auch wenn das ebenfalls in C# oder C ginge).
Brater schrieb: > Mh... Bei der Verwendung von Inkrementierung und Dekrementierung ist > sogar ein Fehler drin :P >> int x; >> x=5; >> --x=(++x)--; >> Nein, das Ergebnis ist nicht 4 sondern 6. > Ich musste selbst erst nachdenken, kam aber ebenfalls auf 4 und mein VS > 2010 gab mir Recht. Die Codezeile mit den ++ und -- ist kein korrektes C, deswegen sollte der Compiler eine Fehlermeldung ausgeben. GCC tut das auch:
1 | test.c:8:12: error: lvalue required as decrement operand |
Kar Heinz hat schon recht, wenn er oben schreibt: Karl Heinz Buchegger schrieb: > Jeder der C einigermassen kennt, sieht da aber recht schnell, dass Bernd > von C nicht wirklich Ahnung hat, sondern hauptsächlich rummosert. Und > das zum Teil falsch und zum Teil mit falschen Argumenten. In C++ (was aber nicht das Thema des verlinkten Artikels ist) ist der Ausdruck prinzipiell erlaubt, liefert aber ein undefiniertes Ergebnis. Dabei gibt GCC eine Warnung aus, die auf jeden Fall ernst genommen werden sollte:
1 | test.c:8:14: warning: operation on ‘x’ may be undefined [-Wsequence-point] |
Deswegen braucht auch nicht darüber zu diskutiert werden, ob das Ergebnis 4 oder 6 ist. Beides ist gleichermaßen richtig oder falsch. GCC liefert übrigens weder 4 noch 6, sondern 5.
Yalu X. schrieb: > Brater schrieb: >> Mh... Bei der Verwendung von Inkrementierung und Dekrementierung ist >> sogar ein Fehler drin :P >>> int x; >>> x=5; >>> --x=(++x)--; >>> Nein, das Ergebnis ist nicht 4 sondern 6. >> Ich musste selbst erst nachdenken, kam aber ebenfalls auf 4 und mein VS >> 2010 gab mir Recht. > > Die Codezeile mit den ++ und -- ist kein korrektes C, deswegen sollte > der Compiler eine Fehlermeldung ausgeben. GCC tut das auch: > >
1 | > test.c:8:12: error: lvalue required as decrement operand |
2 | > |
Pelles C meckert auch : error #2088: Lvalue required. Visual C++ 2008 Express Edition moniert ebenfalls error C2105: '--' muss ein L-Wert sein error C2106: '=': Linker Operand muss ein L-Wert sein allerdings nur dann, wenn der Quellcode als .c compiliert wird. Als main.cpp geht's fehlerfrei durch. Ergebnis 4.
Brater schrieb: > Mh... Bei der Verwendung von Inkrementierung und Dekrementierung ist > sogar ein Fehler drin :P
1 | C merkt man an, dass seine Schöpfer noch keine Erfahrungen mit dem Entwurf |
2 | von Programmiersprachen hatten. Es ist sehr unübersichtlich und unlogisch. |
Das ist auch niedlich...
Uhu Uhuhu schrieb: > Brater schrieb: >> Mh... Bei der Verwendung von Inkrementierung und Dekrementierung ist >> sogar ein Fehler drin :P > C merkt man an, dass seine Schöpfer noch keine Erfahrungen mit dem > Entwurf > von Programmiersprachen hatten. Es ist sehr unübersichtlich und > unlogisch. > > Das ist auch niedlich... Das mag etwas übertrieben ausgedrückt sein, aber ich sehe das ähnlich. Jedoch ist C doch schon in irgend einer Form logisch. Man braucht halt länger um den Code zu verstehen/entschlüsseln. Es sei denn man hat den Code selbst geschrieben.
Uhu Uhuhu schrieb: > C merkt man an, dass seine Schöpfer noch keine Erfahrungen mit dem > Entwurf > von Programmiersprachen hatten. Es ist sehr unübersichtlich und > unlogisch. Naja, es hat bei den Entwicklern immerhin für das Dragonsbook gereicht. Ich denke schon, dass sie wussten, was sie tun. Ich vermute eher, das damalige HW Restriktionen ihren Tribut forderten. Da ist man ja heute "etwas" verwöhnter. Aber lass doch mal eine aktuelle JRE auf einer 1MIPS/256K (RAM, nicht Cache) Maschine laufen^^ Grüße Andreas
Andreas H. schrieb: > Uhu Uhuhu schrieb: >> C merkt man an, dass seine Schöpfer noch keine Erfahrungen mit dem >> Entwurf >> von Programmiersprachen hatten. Es ist sehr unübersichtlich und >> unlogisch. Das habe ich nicht geschrieben, sondern aus dem oben verlinkten Pamphlet zitiert. Wenn du zitierst, dann bitte nicht derart grob entstellen.
Andreas H. schrieb: > Naja, es hat bei den Entwicklern immerhin für das Dragonsbook gereicht. Die Bücher mit dem Drachen wurden nicht von den C-Entwicklern geschrieben. Immerhin hatten sie aber den gleichen Arbeitgeber.
Uhu Uhuhu schrieb: > Das habe ich nicht geschrieben, sondern aus dem oben verlinkten > Pamphlet zitiert. > Oh, sry. Das war für mich nicht als Zitat erkennbar (wo, sagtst Du, hast Du die Quelle angegeben ?) Viele Grüße Andreas
Yalu X. schrieb: > Die Bücher mit dem Drachen wurden nicht von den C-Entwicklern > geschrieben. Stimmt. Ich dachte immer, dass das die gleiche Arbeitsgruppe war. Grüße Andreas
Rainer S. schrieb: > > Das mag etwas übertrieben ausgedrückt sein, aber ich sehe das ähnlich. > Jedoch ist C doch schon in irgend einer Form logisch. Ich finde C eigentlich gar nicht so schlimm. Gut, zugegeben, bei manchen Dingen braucht man schon seine Weile, bis man die Logik verstanden hat (die oft viel einfacher ist, als man ursprünglich dachte), aber im Großen und Ganzen finde ich nicht, dass C grob unlogisch wäre. > Man braucht halt > länger um den Code zu verstehen/entschlüsseln. Alles Gewohnheitssache. Die Dichte an Sonderzeichen ist ein klein wenig höher (in einem realen Programm, nicht in diesen aufgemotzen 'Ich zeige mal was in C noch so alles geht' Beispielen), aber wenn man die wichtigsten erst mal intus hat, ist das halb so wild. Überhaupt muss man gerade bei C sehr aufpassen. Da werden oft Beispiele präsentiert, mit denen Punkte untermauert werden sollen, die tatsächlich ekelhaft sind. Die aber in einem Programm aus der realen Welt niemals vorkommen würden und wenn, dann würde der Programmierer von seinem Vorgesetzten mit dem nassen Fetzen erschlagen. Was natürlich stimmt: In C gibt es kein Sicherheitsnetz. Daran muss man sich gewöhnen. Array-Out-Of-Bounds Addressierung interessiert weder Compiler noch Runtime sondern ist das Bier des Programmierers. C hat halt die Prämisse "You don't get, what you didn't ask for".
Uhu Uhuhu schrieb: > Wenn du zitierst, dann bitte nicht derart grob entstellen. Das aber auch sowenig Öl sooo lange reicht, das hätte ich jetzt nicht gedacht ;-) Also hier etwas "Gegenöl": http://www.familientherapie-essen.de/PDFe/zwei_Moenche.pdf
Karl Heinz Buchegger schrieb: > Ich finde C eigentlich gar nicht so schlimm. > Gut, zugegeben, bei manchen Dingen braucht man schon seine Weile, bis > man die Logik verstanden hat (die oft viel einfacher ist, als man > ursprünglich dachte), aber im Großen und Ganzen finde ich nicht, dass C > grob unlogisch wäre. Die Pointerarithmetik von C ist sowas von logisch - und wird von Halbwissern natürlich entweder nicht registriert, oder nicht verstanden...
Uhu Uhuhu schrieb: > Die Pointerarithmetik von C ist sowas von logisch Nicht nur die: Ein Großteil der Sprachelemente erschließen sich einem sofort. Einige Dinge erscheinen auf den erste Blick seltsam bis unlogisch, sind aber nachvollziehbar und gut zu merken, wenn man sich die technischen Gründe dafür vor Augen hält (bspw. die Behandlung von Arrays). Einige Dinge sind zwar logisch, aber für Nutzer anderer Programmiersprachen ungewohnt (Syntax von Datentypen). Einige Dinge sind zwar logisch halbwegs sinnvoll, aber schwer zu merken (bspw. die Integer-Promotion). Ein paar wenige, wirklich schräge Dinge bleiben (bspw. die Operatorrangfolge von &, ^ und | im Vergeleich zu == und !=). Die haben keine technischen, sondern historische Gründe (Abwärtskompatibilität). Die Forderung nach Abwärtskompatibilität ist der größte Verschmutzungsfaktor in der Evolution von Programmiersprachen, und das betrifft nicht nur C, sondern jede Sprache, die älter als etwa 10 Jahre ist.
Yalu X. schrieb: > Die Forderung nach Abwärtskompatibilität ist der größte > Verschmutzungsfaktor in der Evolution von Programmiersprachen, und das > betrifft nicht nur C, sondern jede Sprache, die älter als etwa 10 Jahre > ist. Ist bei Freepascal auch ein ganz großes Thema. Das muss alles kompatibel zu allen möglichen Derivaten sein.
C++ ein Scherz? http://magazin.c-plusplus.de/artikel/%28Humor%29%20Die%20Entstehungsgeschichte%20von%20C
Free Pascal sieht wirklich nicht schlecht aus, Respekt an die Entwickler. Ich hab ein bisschen damit herumgespielt und frage mich ob ObjPascal nun automatisierte Destruktoren hat oder warum die bei mir nicht funktionieren wollen. Falls es die nicht gibt, wäre das ein großes Manko gegenüber C++. RAII ist das was C++ zurzeit so stark macht. Hier mal der Code:
1 | program Test; |
2 | |
3 | {$mode objfpc}{$H+}
|
4 | |
5 | type |
6 | TFish = class |
7 | public |
8 | constructor Create; override; |
9 | destructor Free; override; |
10 | end; |
11 | |
12 | constructor TFish.Create; |
13 | begin |
14 | writeln('blubb');
|
15 | end; |
16 | |
17 | destructor TFish.Free; |
18 | begin |
19 | writeln('blubb');
|
20 | end; |
21 | |
22 | var |
23 | fish: TFish; |
24 | begin |
25 | fish := TFish.Create; |
26 | //fish.Free; |
27 | end. |
Es kommt kein zweites blubb. Getestet mit:
1 | Free Pascal Compiler version 2.6.2 [2013/02/16] for i386 |
unter Linux x86_64.
Timbo1 schrieb: > C++ ein Scherz? > http://magazin.c-plusplus.de/artikel/%28Humor%29%20Die%20Entstehungsgeschichte%20von%20C Spass am Rande: Es gibt eine Sprache, die sieht im realen Leben wirklich so aus, wie der Jux in diesem Artikel über C: http://aplwiki.com/SieveOfEratosthenes?highlight=%28%5CbCategoryShowcases%5Cb%29 http://www.computerhistory.org/atchm/the-apl-programming-language-source-code/
Habe ein bisschen recherchiert, tja einen automatischen Aufruf des Destruktors scheint es einfach nicht zugeben. Ach Leute das ist doch Scheiße. Man wird ja nicht einmal gewarnt, dass man den Destruktor nicht aufruft und, das auch noch wenn die Variable lokal zu einer Funktion gehört -.-. Tut mir Leid, auch wenn ich C++ für ein verdammtes Monstrum halte, das macht C++ definitiv besser. Damit ist Free Pascal nix für mich. Schade. Immer wieder schimpft man auf C und C++, aber eine ernst zunehmende Alternative in der Systemprogrammierung gibts immer noch nicht. In der Anwendungsprogrammierung siehts eigentlich auch nicht anders aus, nix natives mehr, nur noch dieser over bloated Scheiß wie Java. Und das sage ich obwohl ich C# sehr mag, aber warum gibts nicht mal eine Sprache die resourcenschonend UND angenehm zu benutzen zugleich ist, natürlich mit Zeigerarithmetik und Kontrolle ob nun ein Objekt auf den Stack oder Heap landet. Wenn die Sprache einen GCC aufzwingt ists sowieso vorbei, RAII ist besser.
Christopher C. schrieb: > das auch noch wenn die Variable lokal zu einer Funktion > gehört -.-. Mir scheint, dass du nicht viel von Pascal und seinen Nachfolgern verstanden hast? Das Objekt wird mit create auf dem Heap angelegt, ist damit quasi global. Es darf dementsprechend nicht einfach destroyed werden, wenn eine Prozedur beendet wird. Stell es dir als einfache Pointerliste vor, die durch so eine Automatik brechen würde.
Guido B. schrieb: > Christopher C. schrieb: >> das auch noch wenn die Variable lokal zu einer Funktion >> gehört -.-. > > Mir scheint, dass du nicht viel von Pascal und seinen Nachfolgern > verstanden hast? Das Objekt wird mit create auf dem Heap angelegt, > ist damit quasi global. Es darf dementsprechend nicht einfach > destroyed werden, wenn eine Prozedur beendet wird. Das ginge problemlos, wenn feststeht das nichts anderes auf dieses Objekt zeigt. Was hier im Beispiel sogar vom Compiler festgestellt werden kann und Delphi seit Ewigkeiten für einige interne Typen macht und mittlerweile wohl auch darüber hinaus 2). Ansonsten wäre die einfachste Methode reference counting (Problem: heap fragmentation, das aber für viele Fälle gelöst ist 1)), wie das automatisch funktioniert s. z.B. 3) 1) u.a. The Memory Fragmentation Problem: Solved?, Johnstone, Wilson, 1997 2) http://docwiki.embarcadero.com/RADStudio/XE4/de/Automatische_Referenzz%C3%A4hlung_in_mobilen_Delphi-Compilern 3) http://clang.llvm.org/docs/AutomaticReferenceCounting.html
Klar lässt sich das machen, ist die Aufgabe eines Garbage-Collectors. Aber ohne diesen kann man doch das Objekt beim Verlassen einer Prozedure nicht einfach wegräumen?
Christopher C. schrieb: > Falls es die nicht gibt, wäre das ein großes > Manko gegenüber C++. Christopher C. schrieb: > Immer wieder schimpft man auf C und C++, aber eine ernst zunehmende > Alternative in der Systemprogrammierung gibts immer noch nicht. Wat ne Laberei: Es werden wieder Äpfel mit Birnen verglichen. 1. C ist nicht C++ 2. Pascal ist nicht Delphi 3. In einem anderen Thread zu gleichen Thema wurde ermittelt, dass es nur eine Sache in C gibt, die nicht in Pascal umgesetzt werden kann. Ob das so wichtig ist, möge jeder selbst entscheiden.
Jedem das Seine schrieb: > Christopher C. schrieb: >> Falls es die nicht gibt, wäre das ein großes >> Manko gegenüber C++. > > Christopher C. schrieb: >> Immer wieder schimpft man auf C und C++, aber eine ernst zunehmende >> Alternative in der Systemprogrammierung gibts immer noch nicht. > > Wat ne Laberei: Es werden wieder Äpfel mit Birnen verglichen. > 1. C ist nicht C++ > 2. Pascal ist nicht Delphi > 3. In einem anderen Thread zu gleichen Thema wurde ermittelt, dass es > nur eine Sache in C gibt, die nicht in Pascal umgesetzt werden kann. > Ob das so wichtig ist, möge jeder selbst entscheiden. Das ist mir alles bewusst und insofern ist es auch gar nicht die Schuld der Sprachen selbst, nur ist die ganze IT Branche (bis auf die exotischen Bereiche) total fixiert auf C und C++. Gut C ist jetzt eher im Embedded Bereich zu finden und in der Kernelentwicklung, aber die meisten kommerziellen Programme sind in C/C++ geschrieben. C# und Java haben zwar auch ganz schön aufgeholt, fixieren sich allerdings eher im Anwendungsbereich. Selbst wenn eine neue ultimative Sprache erfunden werden sollte, die jeden glücklich machen würde, bräuchte sie ziemlich lang sich zu etablieren. Man kann ja schließlich nicht alle Projekte schnell neuentwickeln. Und das ist das Dilemma. Neh wir nehmen lieber wieder C++, damit haben wir schon immer entwickelt. Vielleicht irre ich mich ja auch.
Guido B. schrieb: > Mir scheint, dass du nicht viel von Pascal und seinen Nachfolgern > verstanden hast? Das Objekt wird mit create auf dem Heap angelegt, > ist damit quasi global. Es darf dementsprechend nicht einfach > destroyed werden, wenn eine Prozedur beendet wird. Stell es dir > als einfache Pointerliste vor, die durch so eine Automatik brechen > würde. Ja, dass Instanzen von Klassen auf den Heap kommen, habe ich erst danach erfahren. Die Frage ist dann halt, warum ist die Variable global? Sie gehört doch in den Scope der Prozedur. Es gibt doch schon einen globalen Scope. Das hast du auch richtig erfasst, das ist das erste mal, dass ich mich näher mit Pascal bzw. ObjPascal auseinandersetze. Wahrscheinlich denke ich zu sehr in C++. Ich habs auch mit Objekten versucht, genau das gleiche, und das obwohl Objekte auf den Stack kommen. Oder verstehe ich da was falsch?
Christopher C. schrieb: > Ja, dass Instanzen von Klassen auf den Heap kommen, habe ich erst danach > erfahren. Die Frage ist dann halt, warum ist die Variable global? Ist sie nicht. Die Variable ist lokal, ist aber offenbar implizit ein Pointer auf ein Klassenobjekt. Der dann, wenn das Objekt wie oben angelegt wurde, in den Heap zeigt. Dieses System hat sich wohl entschieden, ebenso wie viele anderen OOP Sprachen, Klassenobjekte grundsätzlich nicht direkt auf den Stack zu legen. Ihren vollen Sinn entwickelt eine solche Strategie allerdings erst in Verbindung mit Garbage Collection. Guidos Bezeichnung als "quasi global" ist ziemlich problematisch. Der Heap ist vom Scope her weder lokal noch global, sondern genau das was man im Einzelfall daraus macht.
A. K. schrieb: > Guidos Bezeichnung als "quasi global" ist ziemlich problematisch. Ja, der Heap schwebt irgendwie über den Kontexten. Trotzdem müssen die Pointerelemente als global angenommen werden, sonst könnte man nicht von überall im Programm darauf zugreifen (auch wenn sie jenseits des Horizontes liegen).
auch wenn es wieder einen Sturm der Entrüstung verursacht :-) Wollte hier mal ein größeres Pascal Projekt zeigen. Ich selber vertrete nach wir vor die Meinung das die Programmiersprache eigentlich egal ist, aber Pascal durch die strenge Typprüfung einfach zuverlässiger ist http://www.free-erp.de/ Auch wenn der Threat schon älter ist, aber da ich selber viel in Pascal mache will ich natürlich die Sprache am Leben halten. Und dank Lazarus ist es einfach unglaublich portabel von Win zu Linux oder MacOS etc
Tombo schrieb: > auch wenn es wieder einen Sturm der Entrüstung verursacht :-) > Wollte hier mal ein größeres Pascal Projekt zeigen. So leid wie es mir tut aber was ich auf der WebSite gesehen habe... Hut ab^^ Für sowas gibts keine Haue ;-) Schönes WE noch Andreas P.S: Die Icons im Program sind ja knuffig. Sind die Standardmäßig bei Lazarus dabei ? A.
@ Tombo Als alter Delphi/Pascal Hobby-Programmierer nann ich ebenfalls nur sagen: Hochachtung vor Deinem free-erp Projekt! Gruss Ulrich Albert
Auch wenn das Projekt schön und gut sein mag, mit ein paar Begrifflichkeiten solltest doch vorsichtiger umgehen. ERP ist ein weites Feld, unter EDM und PDM verstehen manche etwas anderes (Engineering Data Mangement, Product Data Magement)
Albert M. schrieb: > Als alter Delphi/Pascal Hobby-Programmierer Da ich schon mit Heimsoeth Turbo Pascal gearbeitet habe, tut mir der Niedergang auch sehr leid. An der Sprache liegt das aber weniger, sondern am Verhalten der Anbieter, es gibt ja nur einen kommerziellen, und der versucht seine Altkunden loszuwerden, um wieder voll abkassieren zu können, so dass ich trotz mehr als 30 Jahren Kundentreue jetzt alles neu bezahlen müsste. Daher verwende ich Delphi7 privat noch solange wie man damit unter Windows noch was zum Laufen kriegt (geht noch ganz gut, Kacheln mag ich eh nicht), aber professionell würde ich wegen der nicht gegebenen Investitionssicherheit kein Pascal mehr verwenden, nicht für ein neues Projekt. Bei C++ kann man immer auf einen anderen Compiler ausweichen. Was Pascal immer gefehlt hat, ist die Konkurrenz durch einen ernstzunehmenden 2. Anbieter. PCs haben sich auch nur so schnell weiterentwickelt, weil es eben nicht nur IBM gab. Georg
Georg schrieb: > nicht gegebenen Investitionssicherheit kein Pascal mehr verwenden, nicht > für ein neues Projekt. > > Was Pascal immer gefehlt hat, ist die Konkurrenz durch einen > ernstzunehmenden 2. Anbieter. Warst Du die letzten 10 Jahre auf interplanetarer Kreuzfahrt jenseits des Asteroidengürtels oder wie kommts dass Du als einziger noch nichts von Lazarus und fpc gehört hast? Oder sollte das ein Trollposting oder ein verkappter flamebait werden?
Bernd K. schrieb: > dass Du als einziger noch nichts > von Lazarus und fpc gehört hast? Das sind eher Absichtserklärungen als fertige Software. Und ich habe schon zu viele Free-Projekte sang- und klanglos untergehen sehen um darauf längerfristig zu bauen. Da heisst es dann "der XY der das bisher gemacht hat, kann aus beruflichen Gründen nicht mehr" und dann kommen Weiterentwicklung und Fehlerbeseitigung zum Erliegen und ein paar Jahre später gibt es nur noch ein paar Unentwegte, die mit den alten Versionen herumspielen. Beispiel CVS, und XFree86 scheint auch ins IT-Nirwana einzugehen, und das sind grundlegende Programme. Ein Begriff wie Investitionsicherheit ist für dich wohl aus einer anderen Welt, für einen Bastler sieht das natürlich alles anders aus. Privat kann ich ja selbst Lazarus mal testen, wenn Delphi7 nicht mehr verwendbar ist und wenn es Lazarus bis dahin noch gibt. Georg
Georg schrieb: > Da ich schon mit Heimsoeth Turbo Pascal gearbeitet habe, tut mir der > Niedergang auch sehr leid. Geht mir genauso!
Georg schrieb: > Ein Begriff wie Investitionsicherheit ist für dich wohl aus einer > anderen Welt, Nein, FPC und Lazarus sind Investitionssichertheit, mehr als es eine Firma Borland oder irgendeine andere längst untergegangene 3-Mann Klitsche je hätte sein können, denn diese Projekte stehen unter der (L)GPL und haben ein ein großes breit aufgestelltes internationales Entwicklerteam, sind sehr lebendig und werden noch aktiv sein wenn Du schon längst in Rente bist. Im übrigen sind sie schon seit Jahren aus dem Stadium "Absichtserklärung" heraus und stellen eine voll nutzbare und aktiv gepflegte Toolchain zur Verfügung und der Support der großen (und stetig weiter wachsenden) Community ist Exzellent. Du solltest nach all den Jahren der Ignoranz vielleicht mal wieder wagen einen Blick drauf zu werfen, dann würdest Du hier nicht so einen haarsträubenden Blödsinn verbreiten über den Zustand von Projekten die Du überhaupt nicht kennst.
Angehängte Dateien:
-
delphi.jpg
22 KB
Bin gerade durch zufall auf noch ein kommerzielles Delphi Produkt gestoßen :-) Leidwer aufgrund einer Fehlermeldung :-( Ist ein Lernprogram mit Spracherkennung..soviel zu Pascal wird im Kommerziellen Feld heute nicht mehr eingesetzt ;-) http://www.amazon.de/digital-publishing-Business-Intensivkurs-Download/dp/B00H2YHIBQ/ref=sr_1_1?ie=UTF8&qid=1423953378&sr=8-1&keywords=Business+Intensivkurs+English+%28Download%29
ach ja, und es war kein Pufferüberlauf :-) Ich vermute es wird ein Windows 7 Problem sein, auf XP gibt es die Meldung nicht..mit Lazarus wäre das wohl nicht passiert ;-)
Hier eine Umfangreiche Lsite von Pascal Programmen :-) Neben Nero Burning Rom, Skype, WinRAR, PArtition MAgic sind eine Menge weitere sehr guter und bekannter Programme dabei https://jonlennartaasenden.wordpress.com/2014/11/06/famous-software-made-with-delphi/
Tom schrieb: > Hier eine Umfangreiche Lsite von Pascal Programmen :-) Nun ja, man kann auch mit einem VW Käfer eine schöne Weltreise machen... Aber aus dem Käfer kann man den Wackeldackel, die gehäkelte Klorollenhaube oder die Blumenvase leicht herausnehmen. Mit dem 'begin' Schlüsselwort habes sie es wohl in den 40 Jahren nicht geschafft. Aber im Ernst -- heute gibt es viele weit schönere und interessantere Sprachen als Pascal. Die Portabilität bleibt allerdings ein Argument.
Ohne es mir angesehen zu haben, meisnt zu C#? Mittlerweile gibt es sogar Pascal für Android converter :-) Ob man damit brauchbar auf spezielle Funktionen zugreifen kann..k.A. aber alleine was die Jungens da alles auf die beine stellen ist einfach super. Das es für ARM Controller auch mit Freepascal bereits in Ansätzen geht ist auch cool http://www.blaisepascal.eu/blaisepascal_37_38/BPM37_38Preview/index.html#14
Salewski, Stefan schrieb: > Aber im Ernst -- heute gibt es viele weit schönere und interessantere > Sprachen als Pascal. Ich habe den Eindruck: Die Syntax der Sprachen wird immer verworrener und die Quelltexte immer schwerer verständlich. Vielleicht ist das Absicht, damit nicht jeder Interessierte einfach so eine Idee in ein Programm umsetzen kann. Das mußte ich mal sagen. MfG Paul
Paul Baumann schrieb: > Salewski, Stefan schrieb: >> Aber im Ernst -- heute gibt es viele weit schönere und interessantere >> Sprachen als Pascal. > > Ich habe den Eindruck: Die Syntax der Sprachen wird immer verworrener > und die Quelltexte immer schwerer verständlich. Vielleicht ist das > Absicht, damit nicht jeder Interessierte einfach so eine Idee in ein > Programm umsetzen kann. > > Das mußte ich mal sagen. > > MfG Paul C++ ist aber immer noch der König der verworrenen Programmiersprachen, wenn man sich die ein oder andere Template-Orgie anschaut. Die neuen Sprachen sind manchmal auf den ersten Blick etwas kryptisch, was aber eher daran liegt, dass diese völlig neue Sprachkonzepte aufgreifen und ältere nicht übernehmen. Sieht man sehr gut an Go oder Rust. Meistens sind deren Sprachkerne auch sehr minimalistisch und überschaubar. Also das was man allgemein an C schätzt.
Salewski, Stefan schrieb: > Aber im Ernst -- heute gibt es viele weit schönere und interessantere > Sprachen als Pascal. Die Portabilität bleibt allerdings ein Argument. An die industrielle Praxistauglichkeit, Vielseitigkeit und unkomplizierte Verwendbarkeit von so mächtigen und ausgereiften Komplettpaketen wie Lazarus/FPC oder Delphi müssen deine "interessanten Sprachen" erst mal rankommen, und zwar wesentlich näher als die üblichen 250km Distanz zwischen Theorie und Praxis, ansonsten bleiben es nur schöne Elfenbeintürme am fernen Horizont die in der Abendsonne glänzen.
Ganz schön abgedriftet, das Thema ist: C oder Pascal. C ist nicht C++ und Pascal ist nicht Delphi. C != C++; Pascal <> Delphi;
dicker, länger, härter schrieb: > Pascal ist nicht Delphi. Pascal ist die in Delphi verwendete Sprache, die selbe Sprache wie auch bei FPC. Und wenn Du jetzt kommst mit "Pascal so wie man es heute verwendet (Delphi oder FPC) ist nicht mehr das selbe Ur-Pascal aus Großvater Wirths Zeiten" dann sage ich das selbe kann man auch für C oder C++ sagen.
so schauts nämlich aus :-) Viele der C Programmierer haben seit JAhren nicht den Blick zur Seite gewagt, es hat sich über all die Jahre einiges! getan. Schon Turbo Pascal hat mit dem was hier oft als Beispiele gegen Pascal gebracht wird, so überhaupt nichts mehr zu tun, bzw treffen die Argumente schon seit über 20 jahren nicht mehr zu! Turbo PAscal 6 bzw 7 war schon nicht umsonst damals sehr!! erfolgreich, der einzgie Grund das es vermasselt wurde, war damals die Weiterentwicklung für Windows, Turbo Pascal für Windows war einfach nur furchtbar da kamen dann C und Basic und übernahmen den MArkt. Heute hat FPC bzw Delphi aufgeholt, aber leider unbemerkt vom Mainstream
Dann ist nach deiner Meinung C die in C++ verwendete Sprache. Merkst du wie du daneben liegst?
nein, ist es nicht, schau Dir mal Lazarus bzw FPC an....bis auf das Visual, kann FPC alles was die Visuel Version dafür auch kann
@Kim Mit Windows wurde auf Objekte umgestellt. Es wurde nicht mehr in C, sondern C++ entwickelt. Bei Pascal nannte man es Objekt Pascal. Man darf es nicht gleich setzen. Im Vergleich von C und Pascal gibt es kaum Unterschiede. Das haben wir hier schon öfter diskutiert.
Paul Baumann schrieb: > Ich habe den Eindruck: Die Syntax der Sprachen wird immer verworrener > und die Quelltexte immer schwerer verständlich. Vielleicht ist das > Absicht, damit nicht jeder Interessierte einfach so eine Idee in ein > Programm umsetzen kann. > > Das mußte ich mal sagen. Nun ja, bei C++ habe ich das auch manchmal gedacht... Bei Python und Ruby ist das aber sicher nicht der Fall, und Go soll ja auch sehr weit in Richtung "Einfachheit" gehen. Julia ist durch seine Anlehnung an Matlab ja von der Syntax auch recht einfach. Aber die Forschung hat in den letzten zwei Jahrzehnten auch viele neue Konzepte entwickelt, von denen vieles dann eben in Sprachen wie Haskell, Rust und Nim einfließt. Und man muss ja nicht gleich alles verstehen.
Viele, was in Delphi oder Lazarus geht oder dort gibt, kennt Pascal doch nicht, oder?
doch eben doch, das meinte ich ja. Sonst wäre Dephi ja was anders.. LAzarus ist ja eigentlich nur eine grafische Oberfläche zum Arbeiten für Freepascal. Freepascal steckt aber immer drunter...
dicker, länger, härter schrieb: > ann ist nach deiner Meinung C die in C++ verwendete Sprache. Nein, dieser Satz ergibt auch keinen Sinn. Beides sind entfernt verwandte Programmiersprachen, die neuere wurde von der älteren inspiriert, überlebt haben beide und werden beide unabhängig voneinander bis heute noch häufig verwendet, die Programmierparadigmen sind sehr unterschiedlich. Delphi ist ein Stück Software. Und darin wird unter anderem auch eine Programmiersprache verwendet und die nennt sich "Object Pascal" und das ist der heute gängige und evolutionär aus der Pascal-Ur-Suppe hervorgegangene Hauptzweig (der dickste Ast mit Abstand und auch weitgehend senkrecht) der Pascal Ahnenreihe, ich würde sagen der legitime Träger des Namens "Pascal" und unangefochtene Thronerbe Es gibt keine Pascal und Pascal++ die parallel von einander entwickelt und überlebt haben es gibt nur einen senkrecht gewachsenen Hauptstamm (Delphi und FPC verwenden ihn) mit viel Grün, gesund und tragfähig, und noch ein bisschen dünnes vertrocknetes Seitengeäst viel weiter unten, jedoch angesichts des kräftigen Hauptstammes kaum noch der Rede wert.
Kim Schmidt schrieb: > doch eben doch, das meinte ich ja. Also kennst du Pascal überhaupt nicht und sprichst wie der Blinde von der Farbe. :-( Dann Vergleich weiter Äpfel mit Kürbissen. :-(
Bernd K. schrieb: > dicker, länger, härter schrieb: > ann ist nach deiner Meinung C die in C++ verwendete Sprache. > > Nein, dieser Satz ergibt auch keinen Sinn. Beides sind entfernt > verwandte Programmiersprachen, die neuere wurde von der älteren > inspiriert, überlebt haben beide und werden beide unabhängig voneinander > bis heute noch häufig verwendet, die Programmierparadigmen sind sehr > unterschiedlich. > > Delphi ist ein Stück Software. Und darin wird unter anderem auch eine > Programmiersprache verwendet und die nennt sich "Object Pascal" und das > ist der heute gängige und evolutionär aus der Pascal-Ur-Suppe > hervorgegangene Hauptzweig (der dickste Ast mit Abstand und auch > weitgehend senkrecht) der Pascal Ahnenreihe, ich würde sagen der > legitime Träger des Namens "Pascal" und unangefochtene Thronerbe > > Es gibt keine Pascal und Pascal++ die parallel von einander entwickelt > und überlebt haben es gibt nur einen senkrecht gewachsenen Hauptstamm > (Delphi und FPC verwenden ihn) mit viel Grün, gesund und tragfähig, und > noch ein bisschen dünnes vertrocknetes Seitengeäst viel weiter unten, > jedoch angesichts des kräftigen Hauptstammes kaum noch der Rede wert. Was für ein Schwachsinn! Delphi und Lazarus haben mit Pascal genauso viel zu tun, wie C++ mit C. Grundlegende Syntaxelemnte sind identisch, aber die objektorientierten Sprachen haben erhebliche Erweiterungen, die mit der strukturierten Sprache nicht gemeinsam sind. Ein C++ Compiler frisst problemlos C Code, oder? (Den richtigen Einsatz von Datentypen setze ich voraus: wg. Typeprüfung)
dicker, länger, härter schrieb: > Ein C++ Compiler frisst problemlos C Code, oder? Nein. Nicht jeden.
siehst Du völlig falsch. Du könntest eins zu eins Code aus Delphi ins DOS Freepascal kopieren..hättest lediglich Probleme mit den fehlenden Units wir Forms, FileUtils etc alles was halt für die graphische Oberfläche ist! Genau deshalb denke ich, wenn viele wüßten, wie genial PAscal eigentlich aufgebaut ist und über all die Jahre gewachsen ist, würden es auch viel mehr benutzen! Eine Sprache wurde entwickelt und bis heute erweitert und verbesser so wie es eigentlich sein sollte, anstatt jedesmal das Rad neu zu erfinden, wenn es gar nicht erforderlich ist. ICh denke auch, das einfach zu wenig Öffentlichkeitsarbeit seitens der Pascal Community stattfindet, das ist ein großer Fehler
dicker, länger, härter schrieb: > Ein C++ Compiler frisst problemlos C Code, oder? (Den richtigen Einsatz > von Datentypen setze ich voraus: wg. Typeprüfung)
1 | int* ptr = (int*)malloc(sizeof(int)); |
Wenn man das sieht, weiß man bescheid ;)
gleich als erstes auf der Lazarus Seite steht auch... "Lazarus is a Delphi compatible !!! cross-platform IDE for Free Pascal.!!! It includes LCL which is more or less compatible with Delphi's VCL. Free Pascal is a GPL'ed compiler that runs on Linux, Win32, OS/2, 68K and more. Free Pascal is designed to be able to understand and compile Delphi syntax, which is OOP. Lazarus is the part of the missing puzzle that will allow you to develop Delphi like programs in all of the above platforms. Unlike Java which strives to be a write once run anywhere, Lazarus and Free Pascal strives for write once compile anywhere. Since the exact same compiler is available on all of the above platforms it means you don't need to do any recoding to produce identical products for different platforms."
Vielleicht mal kurz zur Namensentwirrung: Die in diesem Zusammenhang relevanten Programmiersprachen heißen C, C++, Pascal und Object Pascal. C++ und Object Pascal sind die weitgehend abwärtskompatiblen objektorientierten Erweiterungen von C bzw. Pascal. C und Pascal haben keine spezifische Unterstützung für objektorientierte Programmierung. Es gibt ein offizielles C (ISO/IEC 9899:2011), ein offizielles C++ (ISO/IEC 14882:2014), ein offizielles Pascal (ISO/IEC 7185:1990), aber mehrere Object-Pascal-Dialekte¹. Delphi und Lazarus sind Entwicklungsumgebungen für Object Pascal. Delphi wird manchmal (nicht ganz korrekterweise) auch als Bezeichnung für den in dieser Entwicklungsumgebungen verwendeten Object-Pascal- Dialekt verwendet. Free Pascal ist ein Compiler für Object Pascal, der in Lazarus verwendet wird. ——————————— ¹) In der 90er Jahren gab es einen Vorstoß, auch Object Pascal zu standardisieren, der allerdings allerdings auf Grund mangelnden Interesses und des Fehlens einer Referenzimplementation scheiterte.
:
Bearbeitet durch Moderator
dicker, länger, härter schrieb: > Delphi und Lazarus haben mit Pascal genauso viel zu tun, wie C++ mit C. Delphi und Lazarus verwenden Pascal. Das moderne Pascal, die langsam und geradlinig gewachsene Weiterentwicklung der selben Sprache. Irgendwann zu Borlands Zeiten noch und da war es schon die dominante Variante hat man es dann auch als "Object Pascal" bezeichnet um der über die Zeit gewachsenenen Mächtigkeit auch im Namen gerecht zu werden. Das alte Ur-Pascal das Du ständig aus dem Grab hervorholen und klrampfhaft mit C assoziieren willst nur damit Du ein Pascal-Äquivalent für diese unsägliche C/C++-Dualität herbeireden kannst existiert nicht. Diese Dualität existiert nicht! Niemand verwendet außerhalb des Museums noch die alte Ur-Version, das heutige industrielle Pascal ist das von Delphi oder FPC.
:
Bearbeitet durch User
wie gesagt, ich denke wenn das mehr bekannt wäre, würde Pascal /Lazarus wieder erheblich erfolgreicher sein... Ein Marketingproblem :-(
Kim Schmidt schrieb: > gleich als erstes auf der Lazarus Seite steht auch... > "Lazarus is a Delphi compatible !!! cross-platform IDE for Free > Pascal.!!! It includes LCL which is more or less compatible with > Delphi's VCL. Free Pascal is a GPL'ed compiler that runs on Linux, > Win32, OS/2, 68K and more. Free Pascal is designed to be able to > understand and compile Delphi syntax, which is OOP. Lazarus is the part > of the missing puzzle that will allow you to develop Delphi like > programs in all of the above platforms. Unlike Java which strives to be > a write once run anywhere, Lazarus and Free Pascal strives for write > once compile anywhere. Since the exact same compiler is available on all > of the above platforms it means you don't need to do any recoding to > produce identical products for different platforms." Lazarus und Delphi bauen auf Pascalsyntax auf, haben aber wesentliche Erweiterungen!!! http://www.moorecad.com/standardpascal/standards.html Wenn du den Blödsinn immer wiederholt, muss ich daraus ableiten, dass für dich C++ und C auch das Gleiche sind! :'(
Bernd K. schrieb: > dicker, länger, härter schrieb: > Delphi und Lazarus haben mit Pascal genauso viel zu tun, wie C++ mit C. > > Delphi und Lazarus verwenden Pascal. Das moderne Pascal, die langsam und > geradlinig gewachsene Weiterentwicklung der selben Sprache. Irgendwann > zu Borlands Zeiten noch und da war es schon die dominante Variante hat > man es dann auch als "Object Pascal" bezeichnet um der über die Zeit > gewachsenenen Mächtigkeit auch im Namen gerecht zu werden. > > Das alte Ur-Pascal das Du ständig aus dem Grab hervorholen und > klrampfhaft mit C assoziieren willst nur damit Du ein Pascal-Äquivalent > für diese unsägliche C/C++-Dualität herbeireden kannst existiert nicht. > Diese Dualität existiert nicht! Niemand verwendet außerhalb des Museums > noch die alte Ur-Version, das heutige industrielle Pascal ist das von > Delphi oder FPC. Dein begrenzter Horizont entschuldigt das Geschreibsel. :-P In diesem Thread gind es um Pascal oder C für uC. Da gibt es z. Bsp. was von Mikro...Elekt... . Das dürfte mit Delphi ganz wenig zu tun haben. ;-)
:
Wiederhergestellt durch Moderator
nein, Freepascal die aktuelle version hat erweiterungen zur vorgängerversion..das ist richtig, und nichts anderes wir hier ide ganze Zeit gesagt aber z.b den Cardinal Typ kannst Du unter Dos genauso wie unter Windows nutzen. Den gab es in der Turbo PAscal 7 Version noch nicht z.B:
@ dickerlängerhärter Also bisslang bezogen sich die letzten Posts auf Delphi udn Free Pascal offenbar hast Du da was verpasst ;-)
das was Du jetzt anführst mit µc und Mikroe.com stimmt. Liegt aber auch daran das es nicht um einen Standard geht. Auch das wurde bereits erwähnt das die Standatisierungsbemühungen damals nicht fruchteten
dicker, länger, härter schrieb: > Wenn du den Blödsinn immer wiederholt, muss ich daraus ableiten, dass > für dich C++ und C auch das Gleiche sind! :'( Nein. Aber C und C++ werden heute beide noch verwendet, also muss man sie unterscheiden und braucht verschiedene Namen dafür. Bei Pascal wird heute nur noch die aus der Borland-Linie hervorgegangene Variante verwendet, die von Delphi und FPC implementiert werden, alle anderen älteren Dialekte sind ausgestorben oder liegen im Sterben. Außerden hat es nie so einen scharfen Cut und Rewrite und Paradigmenwechsel und grundlegende Änderungen der Grammatik wie zwischen C und C++ gegeben, die Erweiterungen sind eher langsam und natürlich reingewachsen und fügen sich ein als wären sie von Anfang an so geplant gewesen. Das ist der Unterschied.
:
Bearbeitet durch User
dicker, länger, härter schrieb: > Dein begrenzter Horizont entschuldigt das Geschreibsel. :-P > > In diesem Thread gind es um Pascal oder C für uC. Da gibt es z. Bsp. was > von Mikro...Elekt... . Das dürfte mit Delphi ganz wenig zu tun haben. > ;-) Deswegen kann man wohl mit Lazarus/FreePascal auch Software für die ganze ARM-Familie/Cortex erstellen, weil es gar nichts miteinander zu tun hat? So viel zum Thema "begrenzter Horizont" :-)
hmm..schade aber irgendwie kannst Du nicht diskutieren..daher ziehe ich mir hier raus bis gleichwertige Gesprächspartner sich beteiligen. Und ja, da siehst Du mal wir cool FPC ist, das geht tatsächlich! Allerdings ist das meines wissen s noch sehr eingeschränkt kann aber auch an fehlenden units liegen. Derzeit nutzt man für µc überwiegen mikroe oder elab.. aber wie gesagt, diese Art der Konversation ist mir zu blöd, lerne dich entsprechend zu artikulieren oder geh auf Deine C Spielwiese und finde Programmfehler ;-) oder die Tippfehler in meinen Texten wenn es Dir Spaß macht :-)
Bernd K. schrieb: > Bei Pascal wird heute nur noch die aus der Borland-Linie hervorgegangene > Variante verwendet darum dicker, länger, härter schrieb: > Dein begrenzter Horizont entschuldigt das Geschreibsel. :-P Yalu hat freundlicherweise ein wenig aufgeräumt Yalu X. schrieb: > Die in diesem Zusammenhang relevanten Programmiersprachen heißen C, C++, > Pascal und Object Pascal. > > C++ und Object Pascal sind die weitgehend abwärtskompatiblen > objektorientierten Erweiterungen von C bzw. Pascal. C und Pascal haben > keine spezifische Unterstützung für objektorientierte Programmierung. > > Es gibt ein offizielles C (ISO/IEC 9899:2011), ein offizielles C++ > (ISO/IEC 14882:2014), ein offizielles Pascal (ISO/IEC 7185:1990), aber > mehrere Object-Pascal-Dialekte¹. Un der entscheidende Satz: Yalu X. schrieb: > Delphi und Lazarus sind Entwicklungsumgebungen für Object Pascal. @Kim und Bernd Ihr vergleicht C mit Objekt Pascal und das ist wie Äpfel und Kürbisse! Und um noch einaml auf den Eingangspost zu kommen, es geht um: http://www.mikroe.com/mikropascal/arm/ Ob der Delphi-Programme übersetzt? ;-)
?!? schrieb: > Deswegen kann man wohl mit Lazarus/FreePascal auch Software für die > ganze ARM-Familie/Cortex erstellen, weil es gar nichts miteinander zu > tun hat? Und Java läuft auch auf einem Cortex. Oh man .... :-(((
Angehängte Dateien:
-
landspeeder.jpg
42 KB
Oder ums mal anders auszudrücken: Wenn ich sage "ich nehm dem Wagen, das geht schneller als zu Fuß" dann muss natürlich in einer Welt in in der C und C++ bis zum heutigen Tage beide überlebt haben korrekterweise dazu sagen dass ich den Kraftwagen meine und nicht den Pferdewagen. Wenn wir jedoch im Jahre 2015 von Pascal sprechen dann wird doch aus dem Zusammenhang schon klar daß ich mit mit dem Antigrav-Landspeeder in die Stadt fahren will und nicht mit dem Pferdewagen, das muss man doch nicht extra dazuschreiben, oder?
dicker, länger, härter schrieb: > ?!? schrieb: >> Deswegen kann man wohl mit Lazarus/FreePascal auch Software für die >> ganze ARM-Familie/Cortex erstellen, weil es gar nichts miteinander zu >> tun hat? > > Und Java läuft auch auf einem Cortex. Oh man .... :-((( Vielleicht hast du es nicht verstanden. Man kann unter Lazarus direkt native Software für die gesamte ARM-Familie compilieren. Ich spreche hier nicht von einem Cortex, auf dem Linux läuft, unter Linux dann Java und auf dem Java kann man dann Programme laufen lassen. Ich spreche von direkt ausführbaren Programmen nativ auf dem ARM.
dicker, länger, härter schrieb: > ?!? schrieb: >> Deswegen kann man wohl mit Lazarus/FreePascal auch Software für die >> ganze ARM-Familie/Cortex erstellen, weil es gar nichts miteinander zu >> tun hat? > > Und Java läuft auch auf einem Cortex. Oh man .... :-((( Toll. Ein C-Programm, welches auf einem Cortex läuft. Wer hätte das gedacht. Und ich dachte, hier geht es um Pascal/Delphi/Lazarus für einen µC (bsp Cortex)
Ich progge uCs (Mega/XMega) in Pascal :o) Und ich habe keinen Bock mit knapp 50 Jahren noch C zu lernen. Pascal war in meiner Ausbildung ein Steckenpferd unseres Ausbilders und deshalb hatten wir eine ausführliche Pascal-Einführung. Ich hab dann, da mit die Sprache gefällt, privat damit weiter gemacht. Seit aber Pascal dann richtung Windows ging war es mir zu blöd ..... zumal ich sehr lange mit OS/2 gearbeitet habe (Dual-Boot DOS - OS/2).
dicker, länger, härter schrieb: > Crazy H. schrieb: > Ich progge uCs (Mega/XMega) in Pascal > > Wecher Compiler? AVRCo
Crazy H. schrieb: > dicker, länger, härter schrieb: >> Crazy H. schrieb: >> Ich progge uCs (Mega/XMega) in Pascal >> >> Wecher Compiler? > > AVRCo Och Gott, du Armer Kerl. AVRCo ist doch der grottige "Pascal"-Compiler, wo die Cases beim switch mit dem |-Zeichen enden müssen, oder? Und zwar von der Firma, die es seit zehn Jahren nicht schafft, die Bedienungsanleitung(1) mal von "Title of this help project" umzubenennen... Sorry, ich habe jetzt lange genug mit AVRCo und MikroPascal arbeiten müssen. Die Codequalität, die diese Compiler hervorbringen, ist lächerlich: Das Assembly besteht praktisch aus unoptimierte Primitiven. Ich habe zuletzt ein Projekt in C umgesetzt, welches mit GCC und MikroC (dürfte ja dasselbe Backend wie MikroPascal sein) übersetzt wurde. Und selbst mit strammster Optimierung brauchte MikroC etwa drei bis viermal soviel Flash... (1) http://www.e-lab.de/AVRco/DOC_de/DocuReference.pdf
Nase schrieb: > AVRCo ist doch der grottige "Pascal"-Compiler, wo die Cases beim switch > mit dem |-Zeichen enden müssen, oder? Und zwar von der Firma, die es > seit zehn Jahren nicht schafft, die Bedienungsanleitung(1) mal von > "Title of this help project" umzubenennen... Ich merke schon: keine Ahnung
ich war damals von AVRco weg, nachdem mich der Coadmin aus dem Forum geworden hatte, mit den Worten "Du nervst" weil ich zu viele Anfängerfragen gestellt hatte. Mittlerweile vertreibe ich kommerzielle Produkte mit Mirkoe und hätte die große AVRco erworben, aber AVRCo hatte bei mir nach dieser Aktion verschissen. Ich hatte mich dazu damals beim Rolf beschwert, ohne jegliche Reaktion. Wenn die glauebn ohne die Einsteiger und Anfänger auszukommen, dann bitte, sollen die mal alle schön zu Mirkoe rüber, darf Rolf nur nicht maulen nachher!
Mich würde tatsächlich mal der Vergleich AVRCo/Mirkoe zu LunaAVR interessieren. Habt ihr das mal tatsächlich in Erwägung gezogen und probiert?
LunaAVR hatte ich mal ausprobiert. War damlas noch eine sehr junge Version und war damals schon sehr gut! Einzi,g das kein ARM geplant ist hat mich zu Mikroe getrieben. Der Support von LunaAvr ist ebenfalls Klasse. Fehler melden und meist weniger Tage oder am selben Abend behoben!! Aber LunaAVR ist ja kein richtiges Pascal, eher eine Symbiose aus Basic, PAscal und C was aber keinesfalls schlecht ist! Auf meine Intention hin, wurde die Xmega Untetrstützung damals vorgezogen
Vielen Dank für die Rückmeldung! Ich hatte vor geraumer Zeit Mikroe ausprobiert und bin Aufgrund der damaligen sehr frühen Version bei AVRCo gelandet. Im Prinzip recht ordentlich, doch einfach zu teuer für gelegentliche Projekte als Hobbyanwender. Jedes Jahr 25%, ich weiß nicht… Nun schwanke ich, zurück und nochmals Mikroe oder LunaAVR.
das ist der Punkt, laut Rolf muss es das Hobby ja wert sein 'röfl' Also zu meinen reinen Hobbyzeiten wäre es mir das nicht!! wert gewesen, und jetzt Beruflich schon, aber da AVRco nicht sonderlich begeistert von Anfängern ist, müssen sie halt mit den Stammkungen überleben die sie noch haben, großartig neue dazukommen werden bei dem Geschäftsmodell wohl keine emhr und wenn Rolf mal gesundheitlich Probleme haben sollte...dann passiert da gar nichts mehr. Wie gesagt eigentlich schade, hatte mit AVRco angefangen und fand das damals eigentlich nicht schlecht
Ich verwende seit Jahren schon AVRCo Pascal, und bin eigentlich recht zufrieden damit. Anfaenglich hatte ich die Profiversion, bis ich dann merkte, dass die Standard auch genuegt. Natuerlich ohne Wartung, denn die Updates sind mir zu muehsam und machen, dass verschiedene Projekte verschiedene Versionen des Compilers verwenden. Teilweise sind die Aenderungen recht drastisch. dh man muss dann den Code anpassen. Die meisten Projekte sind nach einer Anfangsphase, nach ein paar Iterationen stabil und muessen eher nicht angepasst werden. Wenn ein Produkt draussen ist, wollen die Kunden auch keine Aenderungen mehr. Meist sind die Geraete dann durch eine Zertifizierung durch und somit eingefroren. Da wird dann 10..15 Jahre produziert bis ein Nachfolger kommt. Die Programmiersprache war nie ein Thema, das interessiert niemanden. Was ich muehsam an AVRCo finde ist das Treiberkonzept. Darauf werden viele Resource bei E-Lab verbraten. Ich verwende keinen einzigen. Denn diese sogenannten Treiber sind closed Source und machen irgendwas. Dabei ist es nicht allzu schwierig das Datenblatt eines peripheren Chips zu lesen, und umzusetzen, sodass es in ein eigenes Konzept passt. Ich haette lieber den compiler verbessert, zB 64 bit Variablen. Und smartere Optimierungen. Und..alle 6..7 Jahre kaufe ich mir eine neue Version, zusammen mit einem neuen Notebook.
:
Bearbeitet durch User
Ich habe mit der freien Mega8-Version von AVRCo angefangen und nachdem der uC ausgereizt war die Profiversion gekauft .... 100% Hobby ! @nicht jetzt: es gibt 64Bit-Variablen
Crazy H. schrieb: > Nase schrieb: >> AVRCo ist doch der grottige "Pascal"-Compiler, wo die Cases beim switch >> mit dem |-Zeichen enden müssen, oder? Und zwar von der Firma, die es >> seit zehn Jahren nicht schafft, die Bedienungsanleitung(1) mal von >> "Title of this help project" umzubenennen... > Ich merke schon: keine Ahnung Blah.
Offensichtlich hat Pascal ein großes soziales Problem¹. Nach Lektüre dieses Threads würde ich schon deshalb kein Pascal-Projekt anfangen, weil zu befürchten ist, dass der in 3 Jahren zur Unterstützung eingestellte Pascal-Programmierer in meiner Firma so auftritt wie die Pascal-Fanbois hier im Thread. ¹ wie z.B. auch Lisp, dessen Beherrschung entweder unerträgliches Klugscheißen hervorzurufen scheint oder von vornherein nur unterträglichen Klugscheißern zu gelingen scheint.
na dann sähe es ja für C ganz Schlecht aus...ich finde dafür geht es hier noch sehr sachlich zu. Das hier einzelne etwas unangenehm auffallen, ist nunmal microxontroxler.xxx üblich... Offenbar sind Elektroniker/Programmierer selten Sozial integriert, aber irgendwie ist das ja auch hinlänglich bekannt :-) Aber solange die genug Tippfehler finden andenn die sich hochziehen könnnen oder eine einzige winzige Funktion finden, die PAscal nicht efüllen kann sind die auch glücklich :-)
Postkunde schrieb: > Meine Version hat leider noch kein 64bit float... Das nennt sich auch Fix64: 32Bit Zahl + 32Bit Exponent
Joe G. schrieb: > Nun schwanke ich, zurück und nochmals Mikroe oder LunaAVR. Ich hab mal ein altes AVRCo Projekt auf die Demoversion von mikroPascal PRO portiert. Absolut problemlos! Meine Entscheidung ist gefallen :-)
bin gerade durch Zufall auf eine liste an Pascal Compilern gestoßen die hier sicher gut plazeirt ist http://www.pascaland.org/pascall.htm
Arni schrieb: > liste an Pascal Compilern Schöne Fleissarbeit. Was ich vermisse ist jeweils das Datum der letzten Version, ein Compiler für PDP11 ist sicher nicht von 2015. Ich schätze mal fast alle sind uralt, das eben ist das Problem mit Pascal. Georg
na da kenne ich aber auch genug C Compiler Empfehlungen im Netz die schon ewig nicht mehr existieren ;-) Das Problem gibt es also auch odrt ;-)
Arni schrieb: > na da kenne ich aber auch genug C Compiler Empfehlungen im Netz > die > schon ewig nicht mehr existieren ;-) > Das Problem gibt es also auch odrt ;-) Macht nix, der gcc und clang haben sich halt durchgesetzt, und das zu recht. Klar gibt es noch paar Bastelcompiler (Peles etc.) aber im großen und Ganzen bringt eine wildwuchernde Compilerlandschaft mehr Durcheinander als wie Vorteile.
das stimmt, bei Pascal sind das ja auch nur noch mikro und e-lab und für den PC free pascal (hoffentlich auch in zukunft mit voller unterstützung für die kleinem arm)
Masl schrieb: > Arni schrieb: > Ganzen bringt eine wildwuchernde Compilerlandschaft mehr Durcheinander > als wie Vorteile. Artenvielfalt ist besser. Stell dir vor, es gäbe nur Trabbi und Wartburg. :-(
@ mehr ist mehr (Gast) >> Ganzen bringt eine wildwuchernde Compilerlandschaft mehr Durcheinander >> als wie Vorteile. >Artenvielfalt ist besser. Stell dir vor, es gäbe nur Trabbi und >Wartburg. :-( Da ist was dran! Monokultur ist selten gut. Aber die haben wir nun weiß Gott nicht. Es gibt einige freie wie auch kommerzielle Kompiler, die sich schon einen gescheiten Wettbewerb liefern. Irgendwann ist es aber auch mal gut mit der Artenvielfalt, denn im kommerziellen Umfeld muss man seine Entwicklungskosten auch irgendwann mal wieder reinholen. Das können nicht hunderte von Firmen auf dem Markt. So verschenderisch wie Mutter Natur kann man im Kapitalismus nicht sein. Ausserdem ist der immer auf Kostenminimierung und Effizienzsteigerung aus, Mutter Natur nicht so ganz. Schau dir das Feld der PCs an. Vor 30-40 Jahren gabe es unzählige Start-Ups mit ihren Homecomputer. Die meisten (fast alle) sind schon lange Geschichte. Heute gibt es ausser MAC und Wintel-PC kaum noch was anderes. Smartphones und Tablets sind neue Geräteklassen! Auch die ehrwürdigen Workstation von Sun & Co fristen nur noch ein Schattendasein.
Falk Brunner schrieb: > Schau dir das Feld der PCs an. Vor 30-40 Jahren gabe es unzählige > Start-Ups mit ihren Homecomputer. Die meisten (fast alle) sind schon > lange Geschichte. Heute gibt es ausser MAC und Wintel-PC kaum noch was > anderes. Smartphones und Tablets sind neue Geräteklassen! > Auch die ehrwürdigen Workstation von Sun & Co fristen nur noch ein > Schattendasein. Und nach 30 Jahren startet miteinmal ARM durch, auch im Serverbereich. Wer hätte das gedacht, Totgesagte leben halt doch als arg lang.
mehr ist mehr schrieb: > Artenvielfalt ist besser. Stell dir vor, es gäbe nur Trabbi und > Wartburg. :-( Das ist Ansichtssache. Ich nehme für jedes Target und jede Sprache Eclipse als IDE, und wenn GUI mal nicht geht eben den vim. Wieso soll ich jedesmal auf eine neue IDE umsteigen? Als Compiler ist der gcc gesetzt, wenn er für die Sprache und das Target verfügbar ist. Wieso soll ich jedesmal neue cli-Parameter lernen?
Du sollst dir keine 20 Autos in die Garage stellen, aber 20 Leute müssen nicht alle das gleiche Auto fahren. ;-)
>C++ ist eher was für Masochisten, die eine Sprache andauernd lernen wollen
es sei denn man will nur c mit klassen. so wie arduino das macht...
(...wegen Artenvielfalt...) Falk Brunner schrieb: > Da ist was dran! Monokultur ist selten gut. Aber die haben wir nun weiß > Gott nicht. Es gibt einige freie wie auch kommerzielle Kompiler, die > sich schon einen gescheiten Wettbewerb liefern. Irgendwann ist es aber > auch mal gut mit der Artenvielfalt, denn im kommerziellen Umfeld muss > man seine Entwicklungskosten auch irgendwann mal wieder reinholen. Ähem.. du machst hier einen Denkfehler. Es geht nicht wirklich um Dutzende von C-Compilern, sondern eigentlich um eine Artenvielfalt unter den Programmiersprachen. Das ist ein dezenter Unterschied. Mittlerweile bin ich der Meinung, daß die derzeitige C-Monokultur etwas sehr schlechtes ist - nicht im Moment aber auf lange Sicht, denn C ist ja durchaus benutzbar und Abertausende von jungen Leutchen benutzen C und kennen inzwischen nix anderes mehr. Aber genau das ist der Knackpunkt. C ist eigentlich sehr altertümlich und überhaupt nicht gut reformierbar und das ist ein sicheres Zeichen dafür daß es mit dieser Sprache in Zukunft mehr Probleme geben wird als bisher. Schau nur mal auf die Datentypen: Außer char und int kennt diese Sprache eigentlich nix, denn alles was danach kommt, ist aufgepfropft: long ist eigentlich "long int" und all die neumodichen uint32_t und Konsorten sind ebenfalls nur per typedef aus den zugrundeliegenden Typen gemacht. Und was wird irgendwann mal aus einem 128 Bit Integer? long long long int? Bei Pascal wäre das kein Problem, da würde man einfach nen int128 als neuen echten Datentyp kreieren und fertig. An solchen Details sieht man das Maß an Reformierbarkeit von Programmiersprachen. Und genau deshalb empfinde ich es als wirklich sehr dringend, auch Pascal und auch Basic am Leben zu halten und nicht dem kurzsichtigen Blick auf verfügbare Compiler zu opfern. Allerdings sollte man Leuten wie Mikroe durchaus mal ne Predigt halten. Im Prinzip wäre es ja für einen Compiler für ARM nur wichtig, welche CPU drinnen werkelt und welche Maschinenbefehle man deswegen benutzen kann. Den ganzen Rest wie Speicherlayout und Peripherie-Register könnte man ja den Anwendern selbst überlassen, das Wort 'absolute' ware da extrem hilfreich. Aber bei Mikroe macht man's kompliziert und das schränkt die Anwendung auf wenige µC Typen ein und läßt alle anderen Interessenten im Regen stehen. W.S.
Pascal oder Delphi, Altium sucht sicher Leute die ihre Bugs fixen und Altium ist auch in Delphi geschrieben.
W.S. schrieb: > C ist eigentlich sehr altertümlich [...] > dringend, auch Pascal und auch Basic am Leben zu halten Das gibt für mich wenig Sinn. Basic und Pascal sind in etwa gleich alt. C wurde aber zum Programmieren entwickelt, Basic eher für Kinder, und Pascal für Studenten im erstem Semester. Interessante moderne Sprachen gibt es ja genügend. >Den ganzen Rest wie Speicherlayout und Peripherie-Register könnte man ja >den Anwendern selbst überlassen, Nu ja, der Anwender, wie er in diesem Forum und auch sonst grassiert, will eben alles vorgekaut haben.
W.S. schrieb: > Und was wird irgendwann mal aus einem 128 Bit Integer? > ... > Bei Pascal wäre das kein Problem, da würde man einfach nen int128 > als neuen echten Datentyp kreieren und fertig. Rein technisch wäre es auch in C kein größeres Problem als in Pascal, int128 als vordefinierten Datentyp einzuführen. Man würde damit allerdings in Kauf nehmen, dass alter Quellcode, der selber einen Datentyp namesn int128 deklariert, nicht mehr ohn weiteres kompilierbar ist. In der C-Philosophie ist die Abwärtskompatibilität neuerer zu älteren Standards eines der obersten Ziele. In Pascal wird offensichtlich die Abwärtskompatibilität als nicht so wichtig erachtet, was natürlich mehr Möglichkeiten für Erweiterungen offen lässt. Ob das eher ein Vorteil oder ein Nachteil ist, mag jeder für sich entscheiden. Das hat aber nichts mit der Reformierbarkeit der Sprache zu tun, sondern mit der Abwägung der Sprachentwickler, welchen Kompromiss aus neuen Features und den damit evtl. verbundenen Inkompatibilitäten sie für den jeweiligen Anwender der Sprache als sinnvoll erachten. > long long long int? Diese Syntax, auch wenn sie hässlich erscheint, wäre jedenfalls voll abwärtskompatibel. Ein neuer Typ namens int128 wäre es nicht, weder in C noch in Pascal.
Wenn eine Sprache erweitert wird, können alte Programme immer übersetzt werden. Das geht bei Pascal problemlos und sollte bei C auch gehen, wenn sich an ein paar Regeln gehalten wird.
Salewski schrieb: > und > Pascal für Studenten im erstem Semester. Das hat Apple aber nicht gehindert, Pascal zu dem Standard bei der Entwicklung der Mac Software bis Mac OS 9 zu machen. Manche erinnern sich vermutlich noch an MPW. Erst mit Mac OS X wurde dann umgeschwenkt auf C, und das war erst zur Jahrtausendwende, bzw. 2001.
:
Bearbeitet durch User
:-) Was zeigt, das Apple damals immer schon etwas weiter dachte als die anderen ;-) Böse Zungen behaupten auch, das das noch zu Zeiten war, als MACOs richtig stabil lief ;-) Nur Spaß, macht daraus jetzt nicht gleich wieder trashing :-)
Salewski schrieb: > Das gibt für mich wenig Sinn. Basic und Pascal sind in etwa gleich alt. > C wurde aber zum Programmieren entwickelt, Basic eher für Kinder, und > Pascal für Studenten im erstem Semester. Schon wieder ne Verwechslung. ich meinte nicht ALT sondern Altertümlich. Fortran ist noch viel älter - und doch wird es auch heutzutage immer noch (allerdings in modernisierter Form) für Berechnungen benutzt von Leuten, sie sowas brauchen. Dein Beitrag klingt nach: Basic ist was für Kinder, Pascal für dumme Jungen und nur C ist was für "richtige Männer". Ieks bah. Yalu X. schrieb: > Das hat aber nichts mit der Reformierbarkeit der Sprache zu tun, sondern > mit der Abwägung der Sprachentwickler, welchen Kompromiss aus neuen > Features und den damit evtl. verbundenen Inkompatibilitäten sie für den > jeweiligen Anwender der Sprache als sinnvoll erachten. Nee, das siehst du falsch. Das ewige Argument der angeblich lebensnotwendigen Abwärtskompatibilität ist sowas von strunzfalsch, daß es mir auf die Nerven geht. In Pascal geht all das problemlos, wo du Kompromisse vermutest. Das liegt an der sehr weitsichtigen Grundkonstruktion von Pascal. C ist hingegen damals sehr kurzsichtig konstruiert worden und am häßlichsten sieht man das an den attributorientierten Variablen. Das ist aber nur ein Aspekt von vielen. Sowas kommt davon, wenn Praktiker und keine Akademiker eine Programmiersprache konstruieren wollen: attribute grundtyp name [feldangabe]; oder attribute grundtyp indirektionsmarker name; sind eben eine ausgesprochen BLÖDE Art, etwas zu deklarieren. So etwas MUSS einem irgendwann auf die Füße fallen. Da ist ein var name : typverweis; deutlich klarer strukturiert und deshalb besser handhabbar und auch besser erweiterbar. Auch besser kompilierbar, eben weitsichtiger entworfen. Und genau DAS ist der Punkt, auf dem ich hier herumreite. Yalu X. schrieb: > Rein technisch wäre es auch in C kein größeres Problem als in Pascal.. Da widerspreche ich dir vehement. Sämtliche Erweiterungsversuche in C sind tatsächlich ein größeres Problem. Jedenfalls haben wir es in der Vergangenheit genau so erleben müssen. Und weil wir hier im Mikrocontroller-Forum sind: Denk mal über den Unsinn von printf nach. Bei Pascal hat man mit str und write / writeln einen satz von Pseudofunktionen, die der Compiler selbst auflöst. Da kommt reiner, der aktuellen Funktion angepaßter Maschinencode heraus. Bei C braucht man einen Formatstring und einen Textinterpreter in der Firmware, der selbigen dekodieren soll und der natürlich garnix darüber weiß, was er denn so alles vorgesetzt bekommen wird, obendrein braucht man auch noch solche halsbrecherischen Sachen wie va_arg - und das in einem Mikrocontroller. Kein Wunder, daß nach immer dickeren µC gerufen wird. Oder denk mal über Formulierungen nach wie diese: #define VICFIQStatus (*(volatile unsigned long *) 0xFFFF0004) In Pascal würde das heutzutage etwa so gehen: var VICFIQStatus : dword absolute $FFFF004; Versuche mal spaßeshalber ein Array oder einen Record oder gar ein Objekt in C auf einer bestimmten Adresse mit #define zu definieren. Also das Gegenstück zu var MyObject : TMyObject absolute $4000FF10; Viel Spaß. W.S.
Man könnte jetzt wieder ewig auf die einzelnen Punkte eingehen und Gegenbeispiele konstruieren, aber wieso? Tatsache ist einfach, C hat gewonnen, Pascal hat verloren*, da hilft auch alles lamentieren nichts. *Da ändern auch die 1-2 größeren Projekte, die alle Jubeljahre mal mit Pascal oder einer seiner gefühlten 100 Nachfolgesprachen umgesetzt werden, nichts daran.
W.S. schrieb: > Das liegt an der > sehr weitsichtigen Grundkonstruktion von Pascal. Nun ja. Schon wenige Jahre nach der Vorstellung von Pascal hatte Wirth Modula 1 und 2, und später Oberon kreiert. Soweit ich mich errinnere war Wirth mit dem Erfolg von Turbo-Pascal nicht wirklich glücklich. Pascal sollte eigentlich einfach eine einfache Lehrsprache sein. Sicher hätte Wirth kommeriellen Erfolg von Modula oder Oberon lieber gesehen. Aber der blieb ja doch weitgehend aus, was u.a. wohl auch an der Namensgebung lag. Basic. Pascal und C schleppen viele hässliche Dinge mit. Bei Pascal etwa das "Begin". Von den vielen Basic-Dialekten oder den Delphi Erweiterung weiss ich allerdings nicht viel. Jedenfalls gefallen mir einige der modernen Sprachen wie etwa Nim, D, Rust, Haskell, Julia, Ruby, Python doch deutlich besser, auch wenn ich einige davon nur oberflächlich kenne. Dass ich C und C++ nicht liebe ist ja wohl bekannt, aber mit C kann ich für Mikrocontroller oder auch kleine Anwendungsprogramme leben.
W.S. schrieb: > Das ewige Argument der angeblich lebensnotwendigen Abwärtskompatibilität > ist sowas von strunzfalsch, daß es mir auf die Nerven geht. Nein, falsch ist nur deine Ausdrucksweise: Du persönlich empfindest das Argument der Abwärtskompatibilität als unwichtig. Das ist dein gutes Recht, und deine Meinung wird sogar von prominenten Programmierpsrache- entwicklern wie Guido van Rossum (Python) geteilt. Deswegen ist das Argument aber noch lange nicht falsch. > Das liegt an der sehr weitsichtigen Grundkonstruktion von Pascal. Ich schließe mich diesem Kommentar an: Salewski schrieb: > Schon wenige Jahre nach der Vorstellung von Pascal hatte Wirth > Modula 1 und 2, und später Oberon kreiert. Wenn Pascal tatsächlich so weitsichtig konstruiert war und so problemlos erweiterbar ist, wie du behauptest, warum hat er nicht einfach Pascal weiterentwickelt? Dadurch hätte er Pascal eine sehr viel höhere Chance gegeben, sich zu etablieren. > C ist hingegen damals sehr kurzsichtig konstruiert worden und am > häßlichsten sieht man das an ... Die Punkte, die du ab da anführst, mögen aus der Sicht eines Schöngeists richtig sein. Da sie hier im Forum aber schon zur Genüge diskutiert wurden, möchte ich sie hier nicht weiter kommentieren. > Sowas kommt davon, wenn Praktiker und keine Akademiker eine > Programmiersprache konstruieren wollen: > ... Da du hier C mit Praktikern und Pascal mit Akademikern verbindest: Das gilt nicht nur für die Programmiersprachenentwickler, sondern weitgehend auch für die Anwender. Dies wiederum erklärt, warum C – ganz im Gegensatz zu Pascal – auch heute noch stark im Rennen ist: Der Praktiker sucht die Kontinuität und findet sie bei C, während der Akademiker immer das Neueste mit einem Maximum an Eleganz und Mächtigkeit sucht, das Pascal aber schon lange nicht mehr repräsentiert, nicht einmal mit den vielen Erweiterungen, die es seither erfahren hat.
Yalu X. schrieb: > Wenn Pascal tatsächlich so weitsichtig konstruiert war und so problemlos > erweiterbar ist, wie du behauptest, warum hat er nicht einfach Pascal > weiterentwickelt? Dadurch hätte er Pascal eine sehr viel höhere Chance > gegeben, sich zu etablieren. Hat er doch! Hinter Oberon steckt immer noch Pascal mit denselben Sprachelementen und Strukturen. Die wurden im Wesentlichen nur erweitert, Änderungen waren nur geringfügig und sind zum Teil wohl recht pragmatisch entstanden ("auf Wunsch der Anwender"). So ist beispielsweise die von Stephan kritisierte Flut von "BEGIN" schon in Modula nicht mehr nötig, das 5 Jahre vor Turbo-Pascal entstanden ist. Hierbei wurde gleichzeitig das irritierende "kein Semikolon vor ELSE" mitentsorgt. Das Problem war eigentlich nur, dass der Platzhirsch (Borland) solche Sachen ignoriert hat (Praktiker statt Akademiker) und stattdessen vieles falsch gemacht hat.
@ W.S. (Gast) >Und was wird irgendwann mal aus einem 128 Bit Integer? >long long long int? Ey maaaan, led me dell you this way [reggae] Ive been coding C a lalalala long a lalalala long a lalalala long long le long long long C'mon [/reggae] jamaikanische Grüße Falk ;-)
Falk Brunner schrieb: > [reggae] > Ive been coding C > a lalalala long > a lalalala long > a lalalala long long le long long long > C'mon > [/reggae] Great!
Falk Brunner schrieb: > @ W.S. (Gast) > >>Und was wird irgendwann mal aus einem 128 Bit Integer? > >>long long long int? > > Ey maaaan, led me dell you this way > > [reggae] > Ive been coding C > a lalalala long > a lalalala long > a lalalala long long le long long long > C'mon > [/reggae] Standing across the room I saw you compile Said I want to unit test-test-test For a little while But before I make my move My emotions start running wild My fingers get tied And that's no lie Looking at your eye Looking at your big black eye Ooh yeah And I've got this to say to you Hey! Computer I want to make you sweat Sweat till you can't sweat no more And if you beep I'm gonna push it some, more, more Computer I want to make you sweat Sweat till you can't sweat no more And if you hiss I'm gonna push it Push it, push it some more A la la la la long, a la la la la long long li long long long C'mon A la la la la long, a la la la la long long li long long long So I said to myself Does it link or not? But the dreads done know That executable is his to get With a little bit of this And a little bit of that My lyric goes on the attack My fingers gets tied And that's no lie Looking at your eye Looking at your big black eye Ooh computer And I've got this to say to you Hey! A la la la la long, a la la la la long long li long long long Yeah A la la la la long, a la la la la long long li long long long Push it push it some more A la la la la long, a la la la la long long li long long long Alright A la la la la long, a la la la la long long li long long long Push it, push it some more
Ich hatte mir gerade mal Sleep-Sort angesehen. Die Delphi Version ist bei weitem am umständlichsten: http://rosettacode.org/wiki/Sorting_algorithms/Sleep_sort#Delphi
Salewski schrieb: > Ich hatte mir gerade mal Sleep-Sort angesehen. Die Delphi Version ist > bei weitem am umständlichsten: Sieht aber aber auch verständlicher aus als andere Kameraden. Schreib die Oberon-Lösung (Threads mit Sleep?)! ;-)
Salewski schrieb: > Ich hatte mir gerade mal Sleep-Sort angesehen. Die Delphi Version ist > bei weitem am umständlichsten: > > http://rosettacode.org/wiki/Sorting_algorithms/Sleep_sort#Delphi und auch nur weil die http://docwiki.embarcadero.com/RADStudio/XE7/en/Using_TTask_from_the_Parallel_Programming_Library nicht verwendet wurde..
Ach, wenn man hier mal nach einiger Zeit wieder reinschaut, grinst einen nur "lala long di long" an. Wirklich grandiose Argumente. Yalu X. schrieb: > Da du hier C mit Praktikern und Pascal mit Akademikern verbindest: Nein, so wie du es breit redest, wird es sinnentstellend. Aber das Gefasel über C oder Pascal anhand von Beispielen, wie jemand mit C glücklich ist, führt zu nix. Nichtmal zu einer qualitativen Einschätzung. Yalu X. schrieb: > Der Praktiker sucht die Kontinuität und findet sie bei C, Schau doch mal in dieses Forum: Hier suchen die C-Leutchen nicht nach Kontinuität, sondern einfach nur nach irgend einem Weg, das in C hinschreiben zu können, was sie eigentlich bezwecken wollen - und das fällt ihnen sichtbar schwer, so schwer, daß sie händeringend nach Hilfe schreien. Reicht dir das als Indiz nicht? Versuche doch mal, gute und schlechte Bedingungen für Kontinuität zu verstehen: eine steinalte Pascal-Quelle kann man auch heutzutage noch mit einem modernen Pascal-Compiler übersetzen, weil dort all die neumodischen Schlüsselwörter wie Cardinal, Object, Class und so einfach nicht vorkommen. Aber bei einer attributorientierten Sprache wie C ist das anders, ich habe ja nicht ohne Grund das "long long long int" als anschauliches Beispiel zur Diskussion gestellt. Weite Teile von C sind eben NICHT renovierbar und bleiben als Bremsklotz für die Zukunft erhalten - nenn es Kontinuität wenn du willst, wenngleich das falsch ist. Denk mal an den unsäglichen Krampf von uint32_t und Konsorten und die erwiesene Unfähigkeit, selbst sowas endlich mal vom Kopf auf die Füße zu stellen. Wieviele Argumente willst du denn noch ignorieren? Dein Argument, daß Pascal ja das Rennen gemacht hätte, wenn es besser gewesen wäre, gilt nicht, denn du vernachlässigst ganz andere aber durchaus schwer wiegende Gründe. Pascal war und ist so gebaut, daß man es bei einigermaßen sauberer Quelle auch als Laie fast sofort lesen und verstehen kann - und genau DAS war und ist einer ganzen Zunft berufsmäßiger Programmierer allzeit ein Dorn im Auge, denn sie fürchten um ihre Existenzberechtigung, falls ihr jeweiliger Chef mal ne Quelle liest und dabei zum Schluß kommt "das kann ja jeder, das kann ja sogar ICH lesen". Eine nicht ganz unberechtigte Befürchtung meine ich, wenngleich auch auf einer vermuteten Fehleinschätzung seitens des CHEFFE beruhend. Tja, außertechnische Gründe haben oftmals ein nicht zu unterschätzendes Gewicht. Aber immer nur zu schreiben "wir machen aber alle C - deswegen ist es ja viel besser als der Rest der Welt" finde ich albern. Es beinhaltet keine Analyse der betreffenden Programmiersprache auf ihre tatsächliche Qualität, eben keine Ernsthaftigkeit. Das Argument von den Fliegen kennst du ja. Nun, wir werden es ja sehen, was die Zukunft uns an Programmiersprachen bescheren wird. Vielleicht C++++ oder "einige der modernen Sprachen wie etwa Nim, D, Rust, Haskell, Julia, Ruby, Lisp" - ich frag mich bloß, wo der Vorteil liegen soll, wenn man alle nase lang immer neue "grandiosere" Sprachen wie die genannten erfindet. Gibt's dafür morgen früh auch nen guten Compiler für die Cortex M4 oder PIC16? Bei BASIC bin ich mir ziemlich sicher, daß es die Zeitläufte überstehen wird - auch wenn es nicht grad mein Fall ist und sämtliche C-Leute darüber die Nase rümpfen. W.S.
W.S. schrieb: > Schau doch mal in dieses Forum: Hier suchen die C-Leutchen nicht nach > Kontinuität, sondern einfach nur nach irgend einem Weg, das in C > hinschreiben zu können, was sie eigentlich bezwecken wollen - und das > fällt ihnen sichtbar schwer, so schwer, daß sie händeringend nach Hilfe > schreien. Achso und in Pascal hätten sie diese Probleme nicht gehabt? W.S. schrieb: > Versuche doch mal, gute und schlechte Bedingungen für Kontinuität zu > verstehen: eine steinalte Pascal-Quelle kann man auch heutzutage noch > mit einem modernen Pascal-Compiler übersetzen, weil dort all die > neumodischen Schlüsselwörter wie Cardinal, Object, Class und so einfach > nicht vorkommen. Also ich weiß nicht recht was ich davon halten soll (Quelle Wikipedia): > Es gibt drei Standards, die sich auf Pascal beziehen: > Standard Pascal: ANSI/IEEE770X3.97-1993 oder ISO 7185:1990; > Extended Pascal: ANSI/IEEE770X3.160-1989 oder ISO/IEC 10206:1991; > sowie einen Entwurf zu „Object-Oriented Extensions to Pascal“. > Allerdings sind – wie bei den meisten anderen Programmiersprachen auch – > nur die wenigsten Compiler zu diesen Standards vollständig kompatibel. > Diese Tatsache verleitete Scott A. Moore zu der bissigen Bemerkung „Pascal > is, unfortunately, very much a great improvement on its successors“ > („Pascal ist > leider so ziemlich eine große Verbesserung seiner > Nachfolger“ – damals bereits ein geflügelter Satz). > Selbst großen Compilern wie Delphi oder Free Pascal fehlen bis heute einige > Elemente aus Standard Pascal, während Extended Pascal von kaum einem > unterstützt wird. Lediglich Prospero Pascal ist vollständig kompatibel zu > Extended Pascal, während auch GNU Pascal vollständige Kompatibilität > anstrebt. Sieht nicht so gut aus. Bei C kann man sich mind. auf ANSI C verlassen. W.S. schrieb: > Denk mal an den unsäglichen Krampf von uint32_t und Konsorten und > die erwiesene Unfähigkeit, selbst sowas endlich mal vom Kopf auf die > Füße zu stellen. Und wo ist da jetzt das Problem mit stdint.h? Entweder man benötigt gewisse Zahlenräume -> int... oder gewisse Datentypengrößen -> uintx_t? Wenn es auf der Platform kein uintx_t der benötigen Größe gibt, gibt der Compiler einen Fehler aus. Also? W.S. schrieb: > Pascal war und ist so gebaut, daß man > es bei einigermaßen sauberer Quelle auch als Laie fast sofort lesen und > verstehen kann - und genau DAS war und ist einer ganzen Zunft > berufsmäßiger Programmierer allzeit ein Dorn im Auge, denn sie fürchten > um ihre Existenzberechtigung, Sag mal glaubst du an Märchen? W.S. schrieb: > Aber immer nur zu schreiben "wir machen aber alle C - deswegen ist es ja > viel besser als der Rest der Welt" finde ich albern. Es beinhaltet keine > Analyse der betreffenden Programmiersprache auf ihre tatsächliche > Qualität, eben keine Ernsthaftigkeit. Und einige Leute sollten aufhören Pascal als den heilgen Gral der Programmiersprachen zu verkaufen...
W.S. schrieb: > Nun, wir werden es ja sehen, was die Zukunft uns an Programmiersprachen > bescheren wird. Vielleicht C++++ oder "einige der modernen Sprachen wie > etwa Nim, D, Rust, Haskell, Julia, Ruby, Lisp" - ich frag mich bloß, wo > der Vorteil liegen soll, wenn man alle nase lang immer neue > "grandiosere" Sprachen wie die genannten erfindet. Na ja, manche von denen implementieren andere Paradigmen wie Prozedural und Objektorientiert, z.B. Haskell funktional und LISP listenorientiert.
W.S. schrieb: > Versuche doch mal, gute und schlechte Bedingungen für Kontinuität zu > verstehen: eine steinalte Pascal-Quelle kann man auch heutzutage noch > mit einem modernen Pascal-Compiler übersetzen, weil dort all die > neumodischen Schlüsselwörter wie Cardinal, Object, Class und so einfach > nicht vorkommen. Wie oft muss ich noch wiederholen, dass das nicht stimmt? Prominentes Gegenbeispiel: http://www.moorecad.com/standardpascal/p4.html http://www.moorecad.com/standardpascal/pcom.pas Da wirst du sogar noch ein paar Dinge mehr als nur den Typnamen operator ändern müssen, um das Programm mit einem neueren Pascal-Compiler (wie z.B. Free Pascal) zum Laufen zu bekommen. > Aber bei einer attributorientierten Sprache wie C ist das anders, ich > habe ja nicht ohne Grund das "long long long int" als anschauliches > Beispiel zur Diskussion gestellt. Wie oft muss ich noch wiederholen, dass diese Datentypbezeichnung zwar nicht besonders schön, dafür aber völlig konfliktfrei zum bestehendem C-Code ist? Da die Sequenz "long long long int" nach aktuellem C-Standard ein Fehler ist, wird man sie in keinem C-Quellcode finden. Folglich könnte man einen Datentyp mit dieser Bezeichnung in einen zukünftigen C-Standard aufnehmen, ohne irgendwelche Inkompatibilitäten befürchten zu müssen.
NSA schrieb: > denn sie fürchten >> um ihre Existenzberechtigung, > > Sag mal glaubst du an Märchen? Ich habe im Lauf von einigen Jahrzehnten genug Programmierer kennengelernt, deren Primärziel es war, Code zu schreiben, den ausser ihnen niemand in der Firma versteht (was nebenbei bemerkt für mich ein klarer Entlassungsgrund wäre). Dir fehlt da wohl die praktische Berufserfahrung. Zugegebenermassen ist der Typ im Lauf der Zeit und mit der industriellen "Produktion" von Software seltener geworden. Für sowas ist zwar C nicht absolute Voraussetzung, aber das Verschleiern des Sinns hinter einer Programmkonstruktion fällt doch mit C oder C++ mit Abstand am leichtesten, wenn man einmal von einigen sehr exotischen Sprachen absieht (oder scherzhaft gemeinten wie Brainfuck). Dass man, im Gegensatz dazu, ein Programm wie englischen Klartext lesen kann, spricht noch mehr als für Pascal für die Uralt-Sprache COBOL, und deswegen hat die immer noch immense Bedeutung, auch wenn sie in Foren wie diesem hier konsequent totgeschwiegen wird. Georg
Hallo Rainer, Rainer S. schrieb: > Was spricht für C? Es ist der Industriestandard. Dieser Umstand ist zunächst einmal nur eine Feststellung und wäre alleine noch kein Argument. Aber entscheidend ist das Ergebnis: nämlich die breite Verfügbarkeit von sehr leistungsfähigen, gut getesteten und dokumentierten Werkzeugen und Bibliotheken. Und das ist dann auch für Hobbyprogrammierer wichtiger als viele glauben. Liebe Grüße, Karl
Hallo Christian, Christian Berger schrieb: > Also wenn Du GUI machst, kommst Du im Moment fast nicht um Lazarus rum. > (Pascal basierend) > > C erfordert eine gewisse Erfahrung und Disziplin, das sollte man erst > nach einem Assembler machen. C++ ist eher was für Masochisten, die eine > Sprache andauernd lernen wollen, und denen gutes Sprachdesign egal ist. Man merkt sofort: da spricht der Fachmann. Liebe Grüße, Karl
Hi g., g. c. schrieb: > 5-Sterne-Los schrieb: >> Für C spricht, dass Pascal nie über den Status einer akademischen >> Sprache hinaus kam. Sehr gut für die Lehre (zumindest vor ca. 20 >> Jahren), aber ohne Praxisrelevanz. > > Aber Delphi/Lazarus ist alles andere als eine rein akademische Sprache. > Sonst gäbe es wohl kaum solche Software hier: > > http://www.diptrace.com/ Das ist die berühmte Ausnahme, die die Regel bestätigt. Wenn Du der einen Ausnahme die große Vielfalt ähnlicher Programme gegenüberstellst, die nicht in Delphi/Lazarus geschrieben worden sind, erhälst Du eine ziemlich genaue Annäherung, was mit "nie über den Status einer akademischen Sprache hinaus gekommen" gemeint ist. Nix für ungut! ;-) Liebe Grüße, Karl
Hallo cppler, cppler schrieb: > Also die Programmiersprache ist i.d.R. egal. > Gut Klassiker: > C: "shoot yourself in the foot" > PASCAL: "the compiler wont let you shoot yourself in the foot" Die praktische Erfahrung lehrt, daß man sich mit jeder Programmiersprache in den Fuß schießen kann. Denn immer, wenn Du etwas idiotensicher gemacht hast, kommt die Natur und erfindet bessere Idioten. Liebe Grüße, Karl
Karl Käfer schrieb: > nämlich die breite Verfügbarkeit von sehr > leistungsfähigen, gut getesteten und dokumentierten Werkzeugen und > Bibliotheken. Und das ist dann auch für Hobbyprogrammierer wichtiger als > viele glauben. und jetzt meinst Du das sei ein Alleinstellungsmerkmal für C? Für Pascal/Delphi trifft das im gleichen Masse zu, insbesondere für techn./wissenschaftl. Anwendungen. Aus Erfahrung weiss ich dass C/C++ Programmierer für umfangreiche Applikationen ca. die 3 bis 10 fache Zeit als Delphi Programmierer benötigen. Ich hatte mal ein Dutzend von Beiden als Angestellte, daher kann ich mir dazu ein Urteil erlauben. In C/C++ wurde nur dann programmiert, wenn ein Kunde das unbedingt so wollte. Und was meinst Du wovon Embarcadero ( http://www.embarcadero.com/de ) mit seinen neuesten Delphi-Versionen (Rad Studio) noch existiert. Es gibt jede Menge grosser Industrie-Software die auch heute noch in Delphi geschrieben wird. Das hat wohl seinen Grund. Wo sind denn hier im Forum die C/C++ Programme (ich meine jetzt nicht Embedded für MC's)? Die Projekte hier sind in allem möglichen Programmiersprachen geschrieben, C/C++ hat man darunter nur spärlich entdeckt. Hat wohl auch seinen Grund.
:
Bearbeitet durch User
Hallo, TriHexagon schrieb: >
1 | > int* ptr = (int*)malloc(sizeof(int)); |
2 | >
|
> > Wenn man das sieht, weiß man bescheid ;) Ja, ich weiß Bescheid: wer sowas schreibt, sollte Bäcker werden. Dann kann er den Mist, den er macht, wenigstens essen. Liebe Grüße, Karl
Hallo mehr, mehr ist mehr schrieb: > Artenvielfalt ist besser. Stell dir vor, es gäbe nur Trabbi und > Wartburg. :-( http://en.wikipedia.org/wiki/List_of_compilers Liebe Grüße, Karl
W.S. schrieb: > Nun, wir werden es ja sehen, was die Zukunft uns an Programmiersprachen > bescheren wird. Vielleicht C++++ oder "einige der modernen Sprachen wie > etwa Nim, D, Rust, Haskell, Julia, Ruby, Lisp" - ich frag mich bloß, wo > der Vorteil liegen soll, wenn man alle nase lang immer neue > "grandiosere" Sprachen wie die genannten erfindet. Also Lisp als neu erfundene (!!) ''"grandiosere" Sprache'' aufzulisten ist mutig aber lustig. Kurzer WikiCheck wann folgende Sprachen entwickelt wurden: Fortran 1957, Lisp 1958, C 1972 Natürlich gibt es immer neue Sprachen. Man entwickelt ja auch neue Sprach-/Implementierungskonzepte. Und die sind ja meist "per definition" schon nicht mehr abwärtskompatibel. Und willst Du wirkich heute noch Fortran IV hacken ? /regards Andreas
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.