Anläßlich der unsäglichen Diskussion im Thread Beitrag "Pascal Compiler für PIC - ist wirklich Freeware" , die in einen Glaubenskrieg Pascal <--> C mündete, poste ich mal was zur Versachlichung. Hier ein Artikel von einem Fachmann, der sichtlich etwas von dem Thema versteht http://www.bernd-leitenberger.de/pascal-und-c.shtml Ich empfehle allen C-Freaks sich das mal in Ruhe durchzulesen und erst dann zu posten und nicht gleich die Totschlag-Keule zu schwingen. Da ich den Artikel gelesen habe, gleich meine Meinung dazu: Was Pascal betrifft spricht er mir aus der Seele und deshalb werde ich bei Pascal bleiben, zu C sage ich nix weil ich's nicht benutze. Für mich im Hobbybereich immanent wichtig: Meinen Pascal-Code verstehe ich nämlich sofort, wenn ich nach vielen Jahren problemlosen Einsatze Änderungen einbauen möchte, bei C wäre ich mir da nicht sicher. So, nun haut euch die Köpfe ein. Aber bitte erst den Artikel komplett lesen. koesters60
:
Verschoben durch User
Bernd - ist wieder gegangen schrieb: > So, nun haut euch die Köpfe ein. Aber bitte erst den Artikel komplett > lesen. man braucht in nicht komplett zu lesen. Wenn er hat zwar Ahnung von vielen dingen aber nicht von C. Und wie soll er das etwas sachliches über C schreiben? > StringToUppercase ist das beste beispiel, kein C programmierer würde so jemals so schreiben. Immerhin gibt es die funktion wie toupper
Volle Zustimmung! Den Artikel kenne ich und finde ihn sehr objektiv. Laß dich nicht runtermachen. Ich arbeite auch mit beiden Sprachen (C vorwiegend auf dem AVR und Pascal bzw. Lazarus auf dem PC). Und ich muß immer noch sagen, daß Pascal um Größenordnungen logischer und intuitiver ist als C. Aber der verlinkte Artikel zeigt eben die Unterschiede auf, und das ignorieren die reinen "C-Leute" völlig. Das ist schon fast eine Religion :-)
hilmar schrieb: > Volle Zustimmung! > > Den Artikel kenne ich und finde ihn sehr objektiv. > Laß dich nicht runtermachen. Ich arbeite auch mit beiden Sprachen (C > vorwiegend auf dem AVR und Pascal bzw. Lazarus auf dem PC). Und ich muß > immer noch sagen, daß Pascal um Größenordnungen logischer und intuitiver > ist als C. Aber der verlinkte Artikel zeigt eben die Unterschiede auf, > und das ignorieren die reinen "C-Leute" völlig. Das ist schon fast eine > Religion :-) Was heisst hier fast?
Naja, zur "Versachlichung" trägt das nicht bei. Steht schon in der Überschrift des verlinkten Artikels. C, Basic, Pascal oder was auch immer - die Erwartung an die Sprache ist das Kriterium zur Auswahl. Und da gibt es mindestens soviele Erwartungen wie Anwender. Es ist Jedem seine eigene Entscheidung. Alles andere ist missionieren. Blackbird
Wie diese Diskussion enden wird hat Peter der 1,9-te ja schon angedeutet. >StringToUppercase >ist das beste beispiel, kein C programmierer würde so jemals so >schreiben. Immerhin gibt es die funktion wie toupper ...der natürlich weiß, dass es vergleichbare "fertige" Funktionen in Pascal auch gibt.
Ich habe als Schüler ein Pascal-Programm geschrieben um meine Lateinvokabeln zu trainieren. Ich musste dann das Programm in zwei Programme aufteilen, weil er in einem Programm nicht genug CASE-Fälle bearbeiten kann. Ich habe das Programm mit CASE-Fällen geschrieben. Also wenn es da schon nicht ausgereicht hat, dann ist das wohl eher nichts für den professionellen, hardware-nahen Einsatz. C ist was für Profis. Wie willst du als PASCAL-Coder dich zu Objekt-orientertem Programmieren weiterbilden!?
amateur schrieb: > Wie diese Diskussion enden wird hat Peter der 1,9-te ja schon > angedeutet. > >>StringToUppercase >>ist das beste beispiel, kein C programmierer würde so jemals so >>schreiben. Immerhin gibt es die funktion wie toupper > > ...der natürlich weiß, dass es vergleichbare "fertige" Funktionen in > Pascal auch gibt. richtig, warum sollte ich also dinge vergleichen die schon fertig in der Sprache existieren. Somal die C funktion auch noch fehlerhaft ist und nur die ersten 256 zeichen varbeiten. Vermutlich weil er wie von Pascal gewöhnt ist das String nicht länger sein können.
Hundt schrieb: > C ist was für Profis. Wie willst du als PASCAL-Coder dich zu > Objekt-orientertem Programmieren weiterbilden!? mit Delphi oder ObjectPascal?
Richtig, Object Pascal ist eigentlich schon lange bekannt. Wird auch von FPC / Lazarus unterstützt.
> Wie willst du als PASCAL-Coder dich zu > Objekt-orientertem Programmieren weiterbilden!? Schonmal was von Object-Pascal gehört? Das ist die Sprache, die Delphi und Lazarus benutzen...
für leute die immer noch glauben der vergleich ist sinnvoll: [...] Unions gibt es nur in C. Es sind Bitfelder mit denen man die einzelnen Bits eines Bytes ansprechen kann. [...] soviel zu seinen Kenntnisse in C.
> ...Vergleich von Pascal und VHDL Pascal ist für das Schreiben von Programmen gemacht (sequentielle Abarbeitung) VHDL ist eine Hardwarebeschreibungssprache. Das ist ungefähr das gleiche wie: "Was fährt schneller, ein Auto oder meine Kaffeetasse?" :-)
@Hundt Wenn jemand Probleme mit zu vielen case-Abfragen hat, ändert der Wechsel der Sprache bestimmt nichts... Ich war immer der Meinung, egal ob ich C oder Pascal programmiert habe: Spagetti gehören in den Topf und nicht ins Programm.
Hi @Bernd Warum ignorierst du eigentlich nicht einfach diesen "Glaubenskrieg"? Ich selbst spreche auch nicht "C" und lebe in Ruhe und Frieden und ich vermisse gar nichts. C ist für mich kein Thema weil ich wie du auch im Hobbybereich mit Controllern arbeite. Und Ja, ich spreche neben Pascal und Basic auch Assembler. Pascal (Delphi) und Basic (VB) sind Werkzeuge für den PC. Der Controller selbst wird in der Regel mit Assembler programmiert. Solange keine mathematischen Denksportaufgaben anstehen, reicht das auch. Zum Thema Programmiersprache hab ich ja auch schon genug gesagt. Verfall jetzt nicht auf die gleiche Schiene wie einige C-Freaks und verteidige "PASCAL". Das hast du doch gar nicht nötig. Wenn sie in C sprechen, sollen sie ruhig. Es ist ihr gutes Recht, genauso wie deines das "Pascal" ist. Programmieren hängt nicht an der Sprache, es läuft im Kopf ab. Die Sprache ist nur ein Werkzeug. Sicherlich mag es Vorzüge geben, aber mir ist es genauso wie den anderen 99,9% der Programmierer wichtig, mein Program zu verstehen. Das es ein anderer lesen kann ist erst einmal zweitrangig. Und nebenbei: wer eine Aufgabe nicht klar in ein xbeliebiges Programm umsetzen kann, der braucht auch nicht irgendeine Sprache favorisieren. Und vielleicht tröstet es dich: Die Eisenbahnanlage in Hamburg ist soweit ich mich erinnern kann, auch mit Delphiprogrammen (Pascal) gespickt. Und sicherlich nicht, weils eine tote Sprache ist. Es wär schade, wenn du dich hier deswegen ausklinkst und uns eventuell interessante Applikationen dadurch verloren gingen. Gruß oldmax
hilmar schrieb: > VHDL ist eine Hardwarebeschreibungssprache. > > Das ist ungefähr das gleiche wie: > "Was fährt schneller, ein Auto oder meine Kaffeetasse?" Es ging mir um die Ähnlichkeit der Sprache, denn VHDL hat sich u.a. aus Pascal heraus entwickelt und zunächst war diese ja eine reine Simulationssprache. Dass die Synthese sowas auswertet, kam erst später.
Das schreibt er zu Aufzählungstypen, danach hab ich aufgehört den an den Haaren herbeigezogen Schwachsinn zu lesen... Auch C bietet eine Simulation des Typs als enum. Doch damit hören die Gemeinsamkeiten auf. In C ist es nichts anderes als, dass man etliche #define Zeilen einspart. Da diese Typen intern als Zahlen gespeichert werden, kann man ihnen jede Ganzzahl zuweisen, auch z.B. wahl = 10, obgleich wir nur 4 Farben definiert haben. In Pascal geht die Zuweisung einer Zahl über eine Typkonvertierung und löst einen Fehler aus. Hier wird auch deutlich, dass die fehlende Typisierung von C kein Vorteil ist. Denn: Welchen Sinn soll es ergeben, 10 an eine Variable eines Typs zuzuweisen, für den nur 4 Werte definiert sind? Dann müsste man entweder manuell eine Fehlerprüfung einführen oder den Typ erweitern, oder man arbeitet gleich nur mit #defines und einem unbeschränkten Ganzzahltyp wie int.
Ich habe gerne und viel in Turbo Pascal damals auf dem PC geschrieben und es ging alles was man wollte: Interrupthandling, Hardware über I/O Adressen ansprechen usw. Die Kompilate waren klein und liefen selbst auf 286ern schnell und sicher. Es ist eben auch eine Frage der Verfügbarkeit. Heute gibt es so gut wie keine eleganten Kompiler mehr, wie Turbo Pascal es damals war, das ist aber kein Grund, die Sprache zu verteufeln. Mit Sicherheit kann man in Pascal die gleichen Programmieraufgaben lösen wie in allen anderen Sprachen auch. Heute ist es eben C und C++, die einfach weiter verbreitet sind. Eine Menge Leute würden vermutlich in Pascal schreiben, wenn es doch bloss 'Visual Pascal Express' gäbe, hehehe.
> ...VHDL hat sich u.a. aus Pascal heraus entwickelt
Das wußte ich nicht :-)
Wieder was gelernt... Danke!
Der Vorteil von C war für mich immer, dass man es so gut erweitern kann. Besonders mit dem pointer-Management lassen sich Sachen machen, die in Pascal nicht möglich sein, auch wenn komplizierte, sich selbst aufrufende Funktionen und Datenbäume nicht zum alltäglichen gehören. Man muss immer ein Auge darauf haben, wann etwas wofür entwickelt wurde. Nikolaus Wirth würde sein Pascal heute auch komplett anders anlegen.
Bernds N-Bahn schrieb: > http://www.bernd-leitenberger.de/pascal-und-c.shtml Das klingt für mich nach einem langjährigen Pascal-Programmierer, der zu dumm/faul/eingebildet (unzutreffendes durchstreichen) ist, um C richtig zu lernen, bzw. umzudenken und die Philosophie der Sprache zu erkennen. Von C hat er keine Ahnung. Viele aufgeführte "Fakten" sind falsch und Vorteile werden als Nachteile beschrieben, bzw. nicht als Vorteil erkannt. bestucki, der in C programmiert und Pascal nie erlernt hat.
Diese Diskussion ist überflüssig. Wenn es mir in einem Lokal schmeckt, dann ist es mir egal, wie die Köche ausshen. Und nun dürft ihr darüber streiten, welche Nahrungsmittel mir schmecken und welche nicht... Und wer den Vergleich nicht versteht, sollte weiterhin zu Mc Doof gehen.
> bestucki, der in C programmiert und Pascal nie erlernt hat.
=======================
Wieder ein Blinder, der von Farben spricht.
Viele hier programmieren in beiden Sprachen, können also beide Sprachen
beurteilen und zeigen beiden Sprachen ihren Respekt. Du hast nie Pascal
gelernt, wie du selbst sagst, schimpfst aber darüber. Was soll das?
Beurteilen kann man doch nur das, was man auch kennt, oder? Alles andere
ist nur gedankenloses Nachplappern...
hilmar schrieb: > Beurteilen kann man doch nur das, was man auch kennt, oder? Alles andere > ist nur gedankenloses Nachplappern... Er hat doch gar nix über Pascal gesagt ;) Nur ein bisschen über den Autor des Artikels spekuliert wobei ich mich seiner Meinung anschließen würde... Bei nahezu allen Vergleiche wurde C absichtlich schlecht dargestellt bzw. eigentlich geniale Konzepte als "fail" dargestellt, nur weil der Autor sie nicht versteht.
hilmar schrieb: > Du hast nie Pascal > gelernt, wie du selbst sagst, schimpfst aber darüber. NOP, der hat doch nur über die C-Kenntnisse des Autors gemeckert und sich NICHT an Pascal ausgelassen.
be stucki schrieb: > bestucki, der in C programmiert und Pascal nie erlernt hat. Gratuliere dem Sieger des Armutszeugnisses der Woche.
hilmar schrieb: > Was soll das? Lesen ist wohl nicht deine Stärke. Ich habe nur die "Fakten" über C der oben aufgeführten Seite kommentiert und mir aus dem gesamten Kontext eine Meinung über den Verfasser gebildet. Wo bitte schimpfe ich über Pascal? Beweise bitte!
>bestucki, der in C programmiert und Pascal nie erlernt hat. Weshalb er auch ausgesprochen kompetent für Aussagen wie: >Von C hat er keine Ahnung. Viele aufgeführte "Fakten" sind falsch und >Vorteile werden als Nachteile beschrieben, bzw. nicht als Vorteil >erkannt. ist. ...und bei der Gelegenheit, uns auch gleich mit Beispielen nur so erschlägt.
Bernds N-Bahn schrieb: > Meinen Pascal-Code verstehe > ich nämlich sofort, wenn ich nach vielen Jahren problemlosen Einsatze > Änderungen einbauen möchte Na siehste und genau so ist es bei mir mit C. Was man öfter benutzt, kennt man auch besser. Ich hatte auch mal erst unter CP/M, später DOS3.3 mit Turbo-Pascal angefangen. Aber ich habe dann mal Turbo-C installiert und es gefiel mir besser. Ich bin dann dabei geblieben. Und später kam dann Keil C51 dazu. Wenn was auf dem MC nicht lief, habe ich es auf dem PC debuggen können (als DOS-EXE). Die Verwendung von Sonderzeichen als Kontrollelemente finde ich sogar sehr gut. Es strukturiert den Code besser in eigenen Text (Variablen, Funktionsnamen) und C-Syntax, macht ihn also besser lesbar. Dem Autor des Artikels ist es aus jeder Zeile anzumerken, daß er zwar die C-Syntax kennt, aber nicht sonderlich viel in C programmiert hat.
hilmar schrieb: > Du hast nie Pascal > gelernt, wie du selbst sagst, schimpfst aber darüber. Was soll das? > Beurteilen kann man doch nur das, was man auch kennt, oder? er schreibt aber auch keine großen Artikel über den vergleich von C und Pascal. Und genaus das werfe ich dem Herr Leitenberger vor, er hat keine Ahnung von C und schreibt solche Artikel.
Von allen Programmiersprachen, die ich gelernt habe, ist mir C am schwersten gefallen. Basic und Pascal waren viel leichter zu lernen und anzuwenden. Jetzt könnte ich sagen: "C ist Sch....!". Aber warum soll ich etwas verdammen und schlecht machen, wenn ich nur zu dämlich war, das richtig zu verstehen? Was ich bisher zu lesen bekommen habe in diesem Thread waren nur persönliche Animositäten. Das erwartete Ergebnis (das fertige Projekt, das Gerät und alles was damit zusammenhängt ..) bestimmt die Auswahl der Sprache und nutzt die darin enthaltenen Erleichterungen, Vorzüge, usw. Naja, manchmal bestimmt die Auswahl auch die eigene Unzulänglichkeit, sich eine wandere Programmiersprache anzueignen. Aber da sollte man dann darüber schweigen. Blackbird
Bernds N-Bahn schrieb: > http://www.bernd-leitenberger.de/pascal-und-c.shtml > > Ich empfehle allen C-Freaks sich das mal in Ruhe durchzulesen und erst > dann zu posten und nicht gleich die Totschlag-Keule zu schwingen. Es gibt hier aber nur Totschlagargumente. Jedenfalls bei kleinen Controllern ohne Speicherverwaltung. Hier hat der Programmierer gefälligst dafür zu sorgen dass er weiß was wo in seinem Speicher (RAM) steht. Ich würde mich nicht auf einen Compiler verlassen der dann z.B. String-Variablen dynamisch anlegt und irgendwie verwaltet. Die Syntaxunterschiede in der Sprache sind doch nicht so gravierend dass es sich lohnt darüber zu streiten. Wem die Pointer zu schwer und unverständlich sind, der soll sich auf den Hosenboden setzen und das lernen. Oder es ganz lassen. Oder wie will jemand DMA auf einem Controller benutzen der noch nie was von Pointern gehört hat? Wer sich aufs LED-Blinken beschränken will für den sind Pascal und Basic auf Controllern ausreichend, für alles andere ist C/C++ alternativlos. Alles andere ist wie Klavier spielen nur mit den weißen Tasten. Im PC-Umfeld oder da wo die Hardware über das Betriebssystem angesprochen wird und auch eine ordenliche dynamische Speicherverwaltung und genügend Resourcen vorhanden sind, spricht nichts gegen eine alternative Programmiersprachen. Aber eben nur dort.
Pascal ist ne nette Sprache, damit habe ich programmieren gelernt und sie auch noch lange gerne benutzt. Aber eine Sache verhindert ganz einfach den professionellen Einsatz: Stringbeschränkung auf 255 Zeichen. Der Hit ist der Satz des angeblichen Fachmanns der den oben im ersten Beitrag verlinkten Artikel geschrieben hat. Zitat: "Pascal ist auch sehr gutmütig, wenn man bei Copy, Delete und Insert mehr Zeichen angibt als in den String hineinpassen. Hier wird einfach soviel kopiert, wie die Länge hergibt und der Rest abgeschnitten." Das ist nicht gutmütig, daß ist der absolute Worst Case. Dann schneide ich halt einfach sang und klanglos wichtige Informationen ab. Was würdet ihr sagen, wenn die Bank mal schnell euer 6 Stelliges Guthaben auf dem Sparbuch zu einem 4stelligen macht? Sorry aber dieser angebliche Fachmann ist nicht mehr als ein Fanboy. C hat sich durchgesetzt weil es hier neue effizientere Wege eröffnet hat als Pascal, auf mehr Plattformen verfügbar war und es bessere Compiler gab. Inzwischen gibt es je nach Anwendung auch wieder bessere Konzepte und Programmiersprachen als C.
Warum nicht einfach Praxisorientiert? Zählt mal auf für welche hier gebräuchlichen Mikrocontroller (Hallo Topic!) es entweder frei oder kommerziell verfügbare Compiler für die enstsprechende Sprache gibt. Das es Assembler dafür gibt, davon gehe ich erst mal aus :-) Ich habe auf CP/M, Dos und einer VAX 11/780 (K1840) unter Unix mal mit Pascal hantiert, wobei das an der VAX nur noch rein aus Interesse war. Ich habe es völlig verlernt indessen.. Gruß, Holm
> Eine Menge Leute würden vermutlich in Pascal schreiben, wenn es doch bloss 'Visual Pascal Express' gäbe, hehehe. Es gibt heute Delphi. Und viele Leutze benutzen's. >Pascal ist ne nette Sprache, damit habe ich programmieren gelernt und sie auch noch lange gerne benutzt. Aber eine Sache verhindert ganz einfach den professionellen Einsatz: Stringbeschränkung auf 255 Zeichen. Das waren die sShortstrings, aus 386 Zeiten. Sehr praktisch fuer Buffer, denn man musste sie nicht allozieren, es wurden 256 byte freigehalten. Heute gibt es zusaetzlich die normalen Strings mit 2^32 kapazitaet, die muss man allerdings allozieren. Darueber dann ANSI Strings. Widestrings, usw.
@Udo Strings sind ein schlechtes Beispiel für --Pascal. Es gibt schon seit langem (Wide)Strings die diese Beschränkung nicht haben. Übrigens: Gerade, wenn man viel mit Zeichenketten arbeitet, macht sich die "integrierte" Länge positiv bemerkbar.
Mit dem feinen Unterschied, das C schon immer erweiterbar und brauchbar war und somit toupper zur Sprache gehört. Wirths Pascal war rein akademisch und unbrauchbar für die reale Welt. Erst mit den Borland Turbo Pascal Erweiterungen ist es brauchbar geworden. Aber jeder soll mit dem programmieren was ihn glücklich macht ich habe da keinerlei Sendungsbewusstsein ;)
Ich gebe zu ich habe jetzt erst in den verlinkten Artikel oben hineingelesen, ich habe dann aufgeöhrt, so ein Quatsch. Im Prinzip klagt der Autor ständig das er die Übersicht verliert und das C keine Typprüfungen hat. Der Abschnitt mit kein brauchbarer C-Compiler unter CP/M ist völliger Käse. Zortech-C, Supersoft-C und BDS-C fallen mir ad hoc ein. Die Nörgelei über das break in der switch/case Anweisung zeugt auch nur von Unverständnis, ich benutze genau das fehlende break in einer Statemachine in der Software an der ich gerade bastele. Es ändert sich halt im vorhergehenden case Zweig die variable und dann genau möchte ich auch den nachfolgenden Abschnit ausführen ohne erst noch über Los zu gehen, ich habe die Wahl, bei Pascal aber nicht. Den Abschnitt mit der Cray möchte ich auch gerne in Zweifel ziehen wobei ich mir da nicht 100% sicher bin. So lange ich denken kann liefen "relevante" Crays unter UniCos und das ist Unix, BSD-artig .. in Pascal geschrieben? Naja. Ob man eine Schleife abbricht abhängig davon ab eine Bedingung wahr oder Falsch ist, ist Jacke wie Hose, der Hauptunterschied ist meist ob da ein "<" oder ">" in der Bedingung steht. Was soll das? Der die Großbuchstabenfunktion ist lächerlich.. usw. usf. Ich habe die Lust verloren ,der Vergleich ist nicht fair. Ich nutze C und habe vorher mal Pascal benutzt, stehe diesem nicht irgendwie feindlich gegenüber, aber dieser Artikel beweist nur das der Schreiber weder den Sinn noch die Syntax von C begriffen hat und warum es keine standardmäßigen Typprüfungen gibt. Gruß, Holm
Hans-Georg Lehnard schrieb: > und somit toupper zur Sprache gehört. toupper ist nicht Bestandteil der Sprache C sondern des stdlib! C selbst kennt ohne Library kein toupper.
Hans-Georg Lehnard schrieb: > Erst mit den Borland Turbo Pascal Erweiterungen ist es brauchbar > geworden. Und auch das hatte noch die Beschränkung auf 255 Zeichen. Zumindest bis Turbo Pascal 4. Danach bin ich (auch wegen Diplom und Arbeitgeber) auf C umgeschwenkt. Wenn die Beschränkung inzwischen nicht mehr da ist schön, aber in der Zeit als C groß wurde gab es sie definitiv. Was bei Pascal am meisten genervt hat waren die "begin end", warum kann man das nicht einfach mit einer Klammer lösen.
amateur schrieb: > @Udo > > Strings sind ein schlechtes Beispiel für --Pascal. > > Es gibt schon seit langem (Wide)Strings die diese Beschränkung nicht > haben. > > Übrigens: Gerade, wenn man viel mit Zeichenketten arbeitet, macht sich > die "integrierte" Länge positiv bemerkbar. Doch Strings sind ein sehr gutes Beispiel für Pascal, die gab es im Original überhaupt nicht das kam alles erst mit Turbo Pascal dazu. Vorher gab es Hilfskonstruktionen wie: "varying char of" und das nicht bei allen Pascal Compilern.
Ich vermute mal, dass das Ergebnisse eines Vergleichs von C und Pascal folgendes ganz gut treffen könnte:
1 | Eine Entscheidung, welche Programmiersprache der anderen vorzuziehen ist, |
2 | bleibt meist dem Geschmack oder aber wirtschaftlichen Faktoren überlassen. |
Quelle: http://www.iai.uni-bonn.de/~manthey/SS06/Abschlussvortraege/FolienImhoff.pdf
Harry L. schrieb: > Hans-Georg Lehnard schrieb: >> und somit toupper zur Sprache gehört. > > toupper ist nicht Bestandteil der Sprache C sondern des stdlib! > C selbst kennt ohne Library kein toupper. Deshalb muss man bei C ja nicht die Sprache vergewaltigen, wenn man was sinnvolles dazu fügt. Deshalb kann ich immer noch meine uralten C Quellkodes mit aktuellen C Compilern problemlos übersetzen.
Wie waer es mal mit einem neuen Standpunkt im Streit? :-) Ich kenne beide Sprachen. (Angefangen mit UCSD-P, TP5, ueber MSC, Pearl, Forth, nach gcc, iar-c, Renesas-c) Ich denke das so langsam der Zeitpunkt kommt sich von C zu verabschieden und C++ zu programmieren. Microcontroller sind heute so leistungsfaehig, haben solche Resourcen und die Projekte werden immer dicker, das C da einfach irgendwann unuebersichtlich wird. Da bietet sich eine Objektorientierte Sprache an, einfach weil die Aufgaben die man heute loesst SEHR weit vom blinken einer LED entfernt sind. Gleichzeitig wird man aber nicht auf die Hardwarenaehe wie sie C bietet verzichten wollen. Also sollte man darueber nachdenken auf C++ umzusteigen. Oder vielleicht eine neue Sprache C--, welche im Prinzip wie C++ ist, aber ein paar abgefahrene Sachen fallen laesst die auf Controllern problematisch sind (z.B den Heap :-) und dafuer ein paar Dinge aufnimmt die sinnvoll. (direkte Unterstuetzung von Multitasking fuer Mehrkernprozessoren) (vgl:Propeller) Aber natuerlich ist der Hauptvorteil von C das jeder C kann, das es fuer jeden Controller einen C-Compiler gibt, das die letzten 15Jahre in der Industrie ausschliesslich C verwendet wurde und es da bergeweise Altprojekte gibt. Wenn man bedenkt welche Vorteile es hat das man innerhalb eines Tages die Firma, den Controller, die Oberflaeche und den Compilerhersteller wechseln kann ohne gross was neues zu lernen, dann nimmt man vielleicht ein paar Nachteile gerne in kauf. Olaf
Den einzigen wirklichen Vorteil von Pascal ist: wenn man auf VHDL umsteigt kommt einem die Syntax etwas bekannt vor ;)
Harry L. schrieb: > Hans-Georg Lehnard schrieb: >> und somit toupper zur Sprache gehört. > > toupper ist nicht Bestandteil der Sprache C sondern des stdlib! > C selbst kennt ohne Library kein toupper. Aber die stdlib ist Teil der Sprachdefinition C. toupper gehört damit genauso zu einem C-System dazu, wie es eine for-Schleife tut.
Leute, tut uns einen Gefallen und redet nicht nur über mehr oder weniger lage 2^32 große Strings. Wir sind hier in einem Microcontroller Forum und da geht's um den Einsatz von den kleinen Dingern und nicht um PCs oder andere Großmaschinen. In meinen Prozesssteuerungen (eine PC gesteuerte sehr große Modellbahnanlage) brauchte ich, solange es nicht um "Bildschirm" ging, keine Strings. Mit der Hauptgrund warum ich bei Pascal gelandet war, war aber dass ich ein Real-Time Kernel brauchte, um vernünftig strukturiert real-time Anforderungen zu erfüllen. Und da es nur ein für mein Hobbybuget erträgliches Kernel gab, das aber ein Pascal Interfaces hatte, war's also Pascal. Bei meinen PIC Projekten (für Funktionsdecoder und Fahrpulte) hatte ich auch zunächst mit ASM begonnen und auch recht anspruchsvolle Anwendungen mit Interrupts geschrieben. Nur als ich den PMP Pascal Compiler fand für lau und anfing Teile meiner existierenden Programme auf Pascal um zu schreiben (was wegen meiner TP Erfahrung sehr schnell ging), bemerkte ich dass in der ASM Version unentdeckte Fehler steckten, die mir nachträglich so manches "unerwartete" Verhalten erklärten. Was ich schätze, ist dass man sich bei der Benutzung eines Compilers, da unterscheiden sich C und Pascal allerdings nicht, keine Gedanken machen muß über Bankumschaltungen, Kontext Sichern in ISRs, in welchen Banken lege ich Daten ab, wie optimiere ich Boolsche Variablen, wie verwalte ich Indices (bei Vektoren und Arrays), überhaupt das ganze Thema Tabellen...usw usw, aber das Gesagte gilt für C genauso wie für Pascal, also eigentlich hier offtopics weil es um den Vergleich geht. Da ich durch das Umschreiben auch sehr gut verfolgen konnte, wie sich ASM Code in Pascal änderte, habe ich gelernt dass wenn man in einer Hochsprache mit der Assembler-Brille programmiert, man dem Compiler sehr viel arbeit abnehmen kann und eine Optimierung durch den Compiler oft nicht mehr nötig ist bzw. nicht viel bringt. Also alles mehr oder weniger Argumente dafür, eine Hochsprache mit einem guten Compiler zu benutzen, egal obs nun C oder pascal ist. Assembler bringt sehr oft bei unseren Hobbyanwendungen bezüglich hardware-naher Programmierung nicht viel. Und mal an Appell an die "Profis": dies ist ein Hobby-Forum, denke ich mir mal. Beruflich werden sich wohl kaum Programmierer in einem Internetforum tummeln, um mich weiter zu bilden oder ihre Probleme zu lösen, Studenten mal ausgenommen. Und deshalb lasst uns gegenseitig bitte so antworten, dass es ALLE nachvollziebar verstehen. Das kann man nicht mit Kurzpostings die ein Zitat und einen Einzeiler enthalten und schon gar nicht indem man sein Gegenüber für blöd hält, und ihn das permanent wissen läßt. Eine schönen Abend
Karl Heinz Buchegger schrieb: > Harry L. schrieb: >> Hans-Georg Lehnard schrieb: >>> und somit toupper zur Sprache gehört. >> >> toupper ist nicht Bestandteil der Sprache C sondern des stdlib! >> C selbst kennt ohne Library kein toupper. > > Aber die stdlib ist Teil der Sprachdefinition C. > toupper gehört damit genauso zu einem C-System dazu, wie es eine > for-Schleife tut. Bestimmt nicht, denn dann müsste toupper im Syntaxdiagramm auftauchen.
Meine erste Programmiersprache nach Assembler/MC war Pascal. Nervig ist die episch ausufernde Schreibweise, da ist C herzerfrischend kurz und präzise. 1 Seite Pascal = 1 Zeile C. Dementsprechend einfacher ist der Code auch zu lesen.
Pascal schrieb: > Karl Heinz Buchegger schrieb: >> Harry L. schrieb: >>> Hans-Georg Lehnard schrieb: >>>> und somit toupper zur Sprache gehört. >>> >>> toupper ist nicht Bestandteil der Sprache C sondern des stdlib! >>> C selbst kennt ohne Library kein toupper. >> >> Aber die stdlib ist Teil der Sprachdefinition C. >> toupper gehört damit genauso zu einem C-System dazu, wie es eine >> for-Schleife tut. > > Bestimmt nicht, denn dann müsste toupper im Syntaxdiagramm auftauchen. Schau in die ISO-Norm. Die definiert was C ist. Die ganzen Funktionen aus der stdlib sind dort aufgeführt, inklusive exakter Beschreibung wie sie sich zu verhalten haben. Sie SIND Teil der Definition dessen, was C ist. Wie zum Beispiel auch die Definitionen über den zur Verfügung zu stellenden Zeichensatz. Der taucht auch in deinem Syntaxdiagramm nicht auf. Was ist denn da drann neues, das Teile einer Sprache in der Sprache selber geschrieben werden? Das gibt es doch bei anderen Sprachen genauso!
oldmax schrieb: > Programmieren hängt nicht an der Sprache, es läuft im Kopf > ab. Die Sprache ist nur ein Werkzeug. Sicherlich mag es Vorzüge geben, > aber mir ist es genauso wie den anderen 99,9% der Programmierer wichtig, > mein Program zu verstehen. Das es ein anderer lesen kann ist erst einmal > zweitrangig. Und nebenbei: wer eine Aufgabe nicht klar in ein > xbeliebiges Programm umsetzen kann, der braucht auch nicht irgendeine > Sprache favorisieren. Ich habe jetzt beide Beiträge verfolgt und finde das ist mal ne wirklich objektive aussage. Ich spreche zwar nur "gebrochen" c (da ich gerade erst mit µC's anfange) und habe mit Pascal keine erfahrungen da ich mich verstärkt mit Webanwendungen beschäftigte als ich meine anfänge im bereich "Programmierung" hatte. Meine anfänge dort fand ich recht schnell in php. (Nein das soll jetzt kein vergleich der sprachen werden!) Nun als Anfänger sucht natürlich jeder irgendwann mal nach einer lösung für ein problem. Mir wurden dabei von sehr eingefleischten jsp fans geraten ich solle php sein lassen und lieber jsp lernen. Ich habe mich damals nicht sonderlich davon beeinflussen lassen und bereue es auch nicht. Der grund dafür ist das man in seiner favorisierten sprache früher oder später in der lage sein sollte die gestellte aufgabe in code umzusetzen. Ob nun wie in meinem fall beim basteln einer Dynamischen Webseite, beim Programmieren von Mikrocontrollern oder dem schreiben von anderen Anwendungen der fall ist, spielt keine rolle. Ist zumindest meine bescheidene meinung. Gut wenn die aufgabe es ABSOLUT UNMÖGLICH MACHT (In irgendeiner form!) muss man halt nach einer anderen lösung/sprache suchen. Ansonsten bleibt es die entscheidung des einzelnen wie oder mit was für einer sprache er etwas programmiert solange es den gestellten Anforderungen gerecht wird und derjenige mit dem Ergebniss zufrieden ist. oldmax schrieb: > Es wär schade, wenn du dich hier deswegen ausklinkst und uns eventuell > interessante Applikationen dadurch verloren gingen. Dem kann ich nur zustimmen! Auch wenn ich kein Pascal spreche ist es immer hilfreich zu sehen wie andere etwas umsetzen. Besonders für so leute wie mich die dieses Hobby gerade erst anfangen und eventuell weniger Programmiererfahrung haben. Hier muss man halt ab und an einen beitrag "überlesen". Ich bin bisher einmal auf unschöne art Beleidigt worden in einem beitrag, der aber auch konstruktive kritik enthielt die mir hilfreich und informativ war. Zudem bin ich auch in einem Beiträgen sehr sehr Positiv überrascht worden da sich alle beteiligten größte mühe gegeben haben und sehr geduldig waren. Also nicht unterkriegen lassen! Es gibt hier wie du hoffentlich merkst durchaus menschen die sich gerne alles ansehen ohne die art der umsetzung zu kritisieren. So mein Senf dazu auch wenn es OT is! Schönen abend noch. lg DTX
Liebes Moderatoren-Team, es wäre angebracht gewesen für den Moderator einen Kommentar zu setzen, warum er den Thread nach OffTopics verschoben hat. Mein Grund diesen Thread zu starten war, die unseelige Diskussion in dem Thread über einen Freeware Pascal Compiler für PICs von der Diskussion für oder gegen Pascal bzw C frei zu halten, denn das gehörte da nicht hin; für mich unverständlich warum da kein Moderator eingegriffen hat und den Thread zB geschlossen hätte als absehbar war dass der Thread abgleitet. Eine sachliche Diskussion über ein Thema der Programmiersprachen für PICs ist hier in diesem Forum anscheinend tatsächlich nicht möglich. adee
Pascal schrieb: > Bestimmt nicht, denn dann müsste toupper im Syntaxdiagramm auftauchen. Es gibt kein offizielles Syntaxdiagramm. Nur die Norm. Und die normiert die Standardbibliothek sehr wohl.
Kelvin S. schrieb: > Ich spreche zwar nur "gebrochen" c (da ich gerade erst mit µC's anfange) > und habe mit Pascal keine erfahrungen da ich mich verstärkt mit > Webanwendungen beschäftigte als ich meine anfänge im bereich > "Programmierung" hatte. Das wird schon ;) Die ersten 2 Wochen C sind hart, mehrmals wirst Du versuchen, den PC durch das geschlossene Fenster zu werfen. Dann kommt's so langsam. > Meine anfänge dort fand ich recht schnell in php. (Nein das soll jetzt > kein vergleich der sprachen werden!) PHP habe ich für Websachen auch mal probiert. Es ist halt (gegenüber C) recht lahm und nebenbei auch in C geschrieben. Also bleibe ich auch da beim Original (es sind große Webanwendungen mit Datenbanken selbstgestrickt und SQLite > 1 TB). Ich sehe nicht wie ich das in PHP realisieren könnte. Pascal ist mir auch symphatisch, aber halt eine elende Tipperei. So richtige Unterschiede bestehen zwischen Pascal und C eigentlich nicht: Beide erzeugen ein lauffähiges Programm und das ensteht aus meinen Ideen und ist in Maschinencode.
@Olaf (Gast) >Ich denke das so langsam der Zeitpunkt kommt sich von C zu verabschieden >und C++ zu programmieren. Nö. > Microcontroller sind heute so leistungsfaehig, >haben solche Resourcen und die Projekte werden immer dicker, das C da >einfach irgendwann unuebersichtlich wird. Nö. Du schielst da nur auf die Embedded Computer mit dicken 32 Bit ARM CPUs. Es gibt ein Leben jenseits von 32 Bit. > Da bietet sich eine >Objektorientierte Sprache an, einfach weil die Aufgaben die man heute >loesst SEHR weit vom blinken einer LED entfernt sind. Gleichzeitig wird >man aber nicht auf die Hardwarenaehe wie sie C bietet verzichten wollen. >Also sollte man darueber nachdenken auf C++ umzusteigen. Damit dann noch mehr gejammert werden kann, dass die CPU-Power nicht reicht. Wie z.B. hier. Beitrag "Leistungsstarke Demoprogramme für PanelCard" Das Problem ist noch aktuell, der ARM9 mit 200 MHz und 64 MB RAM, was vor vielen jahren mal eine leistungsstarke Workstation war, ist mit ein paar Fenstern und 10 Messwerte/s überfordert. Sagen die Softwwerker :-( >nimmt man vielleicht ein paar Nachteile gerne in kauf. Dennoch darf man die Nachteile benennen. Ein etwas substantiellere Kritik findet man u.a. hier. http://www.henning-thielemann.de/CHater.html
Harry L. schrieb: > Hans-Georg Lehnard schrieb: >> und somit toupper zur Sprache gehört. > > toupper ist nicht Bestandteil der Sprache C sondern des stdlib! > C selbst kennt ohne Library kein toupper. Sagt Dir der begriff laufzeitBIBLIOTHEK irgend was? Was genau kann ein Pascal System ohne diese bzw. was ist dann Bestandteil der Sprache? Neugierig, Holm
Bernd K. schrieb: > es wäre angebracht gewesen für den Moderator einen Kommentar zu setzen, > warum er den Thread nach OffTopics verschoben hat. Den genauen Grund kenne ich auch nicht, habe aber deine Anfrage mal im Moderatoren-Thread zur Diskussion gestellt. Zum Thema selbst: Bernds N-Bahn schrieb: > http://www.bernd-leitenberger.de/pascal-und-c.shtml Der Artikel wurde in anderen Threads schon oft zitiert und diskutiert: Beitrag "C oder Pascal" Beitrag "Basic und C - Vergleichstabelle gesucht" Beitrag "[Delphi] Byte addieren?" Beitrag "Programmieren für Kinder" Das Problem: Der Autor ist begeisterter Pascal-Programmierer und hat gegenüber C nicht nur eine Abneigung, sondern offensichtlich auch nicht allzu viel Ahnung davon. Der Artikel kann also nur verzerrt sein. Einige Aussagen sind schlicht und ergreifend falsch. Einige der aufgeführten Nachteile von C, die in der Praxis praktisch nie auftreten, werden unsinnig breit getreten. Wenn der Artikel aber andere begeisterte Pascal-Programmierer in ihrer Entscheidung bestätigt und ihre Begeisterung für Pascal noch steigert, ist das IMHO voll in Ordnung. Es gibt nichts Schlimmeres, als bei einer einmal getroffenen Entscheidung ständig im Zweifel zu sein, ob sie auch richtig war. Die C-Programmierer finden bei Bedarf sicher auch einen Artikel, der ihre Entscheidung bestätigt. Man sollte den Artikel eben nur nicht als die einen objektiven Vergleich der beiden Sprachen hinstellen. Generell haben alle Artikel der Sorte "Warum ist Programmiersprache A viel besser als Programmiersprache B" die Eigenschaft, dass sie nur die Vorteile von A und die Nachteile von B aufführen. Besser, aber leider sehr selten, sind Artikel von Autoren, die zwei unterschiedliche Programmiersprachen gleich gut beherrschen und zu etwa gleichen Teilen einsetzen. Sie kennen damit von beiden die Vorteile und Nachteile und sind auch bereit, diese anzusprechen. Es gibt bspw. viele Leute, die sowohl in C als auch Python oder Ruby programmieren. Von denen behauptet kaum einer, dass eine der beiden Sprache absolut top und die andere ein totaler Fail ist. Sie kennen aber von beiden die Grenzen und wissen, wann sie besser die eine und wann die andere einsetzen. Auch wenn die ständigen, sehr kontroversen Diskussionen über Pascal vs. C einen anderen Schluss nahelegen, sind die beiden Sprachen so ähnlich, dass es sich für die wenigsten lohnt, alle beide aktiv zu nutzen. Deswegen legt man sich irgendwann auf maximal eine davon fest und hat nach dieser Entscheidung logischerweise kaum noch positive Argumente für die jeweils andere Sprache parat. Genau aus diesem Grund wird es auch kaum gelingen, einen C-Programmierer zu Pascal zu bekehren oder umgekehrt. Wenn aber doch jemand von einer dieser Sprachen auf die andere umsteigt, dann meist von Pascal nach C und nicht umgekehrt. Ich selber und einige aus meinem Bekanntenkreis gehören zu dieser Gruppe. Ich kenne aber niemanden, der den umgekehrten Weg beschritten hat. Ein Grund liegt sicher darin, dass C von Arbeitgebern stärker nachgefragt wird. Bei mir persönlich war es aber eine freie Entscheidung, denn C gefällt mir trotz der paar Nachteile subjektiv einfach viel besser. Wenn dir Pascal besser gefällt, habe ich damit aber auch kein Problem.
Falk Brunner schrieb: > http://www.wackerart.de/c.html Ja - schön und gut. Ich mag aber das Unvollkommene. Ich fahre auch alte Motorräder und so ein Geraffel. Ich bin weder mit Pascal noch C an Grenzen der Maschine gekommen. Es ist eine Gefühlssache und eigentlich doch nur ein Werkzeug. Zu behaupten "das ist besser" halte ich für sinnfrei bis blödsinnig.
danke für die Antwort des Moderators Yalu X.
Der Vollständigkeit halber möchte ich noch hierauf hinweisen Beitrag "Ein sachlicher Vergleich Pascal <-> C" wo ich meine Beweggründe für das Verschieben dargelegt habe. Yalu hat die wesentlichen Kritikpunkte schon vorweggenommen (ohne daß wir uns darüber abgesprochen hätten).
Joachim Drechsel schrieb: > Die ersten 2 Wochen C sind hart, mehrmals wirst Du versuchen, den > PC durch das geschlossene Fenster zu werfen. Dann kommt's so langsam. Das würde ich ja am liebsten schon wegen des Kanada Adapters den ich mir nachbauen wollte der aber absolut nicht macht was er soll g Aber das ist ein anderes Thema. Ich hab ja den (sehr kleinen) Vorteil das ich den Syntax in c schon recht fließend lesen kann da ich weiß wo was beginnt und endet. Mit der Funktionsreferenz bin ich noch nicht durch aber das wird noch, hab ja zeit. > PHP habe ich für Websachen auch mal probiert. Es ist halt (gegenüber > C) recht lahm und nebenbei auch in C geschrieben. Also bleibe ich > auch da beim Original (es sind große Webanwendungen mit Datenbanken > selbstgestrickt und SQLite > 1 TB). Ich sehe nicht wie ich das in PHP > realisieren könnte. Nun ich habe bisher meist privat mit php gearbeitet und brauche natürlich nicht gerade > 1TB. Würde mich aber interessieren für was man solche mengen an Programmcode für die Funktionalität braucht. Für meine Projekte wurde es natürlich mit steigendem know-how auch weniger Code und entsprechend weniger speicherintensiv. > So richtige Unterschiede bestehen zwischen Pascal und C eigentlich > nicht: Beide erzeugen ein lauffähiges Programm und das ensteht aus > meinen Ideen und ist in Maschinencode. Kann ich nicht beurteilen ob es Unterschiede gibt. Zumindest nicht was die sprachen angeht. (Syntax, Funktionsaufrufe, Arrays, Strings ect.) Das aus beiden sprachen ein lauffähiges Programm erzeugen und beim Kompilieren Maschinencode erzeugt ist ja grundvorraussetzung um µC's zu Programmieren. Yalu X. schrieb: > Den genauen Grund kenne ich auch nicht, habe aber deine Anfrage mal im > Moderatoren-Thread zur Diskussion gestellt. Finde ich klasse! P.S Ja php war früher nur eine Sammlung von C Scripten als es begonnen hat und mit heute auch nicht zu vergleichen. Das wurde mir von jemandem schon recht früh so gesagt. Ah wenn du jetzt alleine auf die SQLite Datenbank ansprichst dann verstehe ich natürlich das man da lieber mit C arbeitet. php ist bei Dateizugriffen wirklich langsam.
@Joachim Drechsel (Firma: JDCC) (scheppertreiber) >> http://www.wackerart.de/c.html >Ja - schön und gut. >Ich mag aber das Unvollkommene. Als Hobbydarf man das sicher. Als Produktivmittel will das KEINER! > Ich fahre auch alte Motorräder >und so ein Geraffel. Ich bin weder mit Pascal noch C an Grenzen >der Maschine gekommen. Es ist eine Gefühlssache Bist du eine Frau? >und eigentlich >doch nur ein Werkzeug. Zu behaupten "das ist besser" halte ich >für sinnfrei bis blödsinnig. Aha, also Wattebällchgenwerfer. Wir haben uns alle lieb. OMG!
Joachim Drechsel schrieb: > Zu behaupten "das ist besser" halte ich > für sinnfrei bis blödsinnig. Sehe ich zu 50% auch so. Trifft eben nur auf Pascal zu. mfg.
Einen sachlichen Vergleich Pascal<->C kann es hier nicht geben. Es wird zu emotional argumentiert. Von der Denkweise stehen Pascal und C sehr sehr nahe. Das eine auf das andere umzusetzen ist beinahe mechanische Angelegenheit. C++ nach ObjectPascal abzubilden ist schon schwierigeres Unterfangen. Ein mit lambda's gespickter Python code, mit lokalen Funktionen, Decoratoren, heterogenen Containern etc. auf C/Pascal abzubilden ist mit grössten Mühe möglich .. wenn lazy evaluation noch ins Spiel kommt, dann fühlen sich Pascal und C beide wie Klotz am Bein an. => Es lohnt sich nicht darüber ausufernd zu diskutieren :)
Yalu X. schrieb: > Wenn aber doch jemand von einer dieser Sprachen auf die andere umsteigt, > dann meist von Pascal nach C und nicht umgekehrt. Ich selber und einige > aus meinem Bekanntenkreis gehören zu dieser Gruppe. <Hand heb> Und in meinem Fall kann ich auch ganz klar einen Schuldigen benennen: (Turbo) Pascal hat sich selber disqualifiziert. Und das kam so: Meine "Karriere" begann mit einem obskuren Basic-Dialekt (KC-Basic). Wurde schnell ergänzt durch Z80 Assembler, später CBM-Basic und 6502 Assembler. Dann kam lange Zeit nichts. Dann eine ausgewachsene CP/M-Möhre (BC5120 - googled das ruhig mal) und da wurde nebem Assembler Turbo-Pascal die "andere" Programmiersprache. Wieder einige Zeit später kam mein erster PC - ein 486er mit DOS/Win3.11. Und jetzt war TP 5.0/6.0 die Programmiersprache der Wahl. Obwohl ich als Student Modula-2 machen muß^Wdurfte. Mit dem tieferen Verständnis kam auch die erste Unzufriedenheit. Der TP-Compiler war zwar rattenschnell, aber auch strunzdoof. So wurde z.B.
1 | Integer x=0, y=0; |
zu (sinngemäß, aus dem Gedächtnis)
1 | MOV AX, 0 |
2 | MOV [x], AX |
3 | MOV AX, 0 |
4 | MOV [y], AX |
Der Compiler konnte sich nicht von jetzt auf gleich merken, daß AX schon 0 enthält. Und das ist nur ein simples Beispiel. Ein anderes Ärgernis waren die Limitierungen der Architektur von Hardware/Betriebssystem. Man mußte sich zwischen Speichermodellen wie Small (Code + Daten < 64K), Compact, Large etc. entscheiden. Aber Datenstrukturen mit mehr als 64K am Stück gingen niemals. Für einen Mathe-Studenten der gerne mal das Sieb von Eratosthenes für große Zahlen programmieren wollte, oder richtig große Fraktale, für den war das eine Zumutung. Noch einer: Rekursion mit einem Fließkomma-wertigen Funktion scheiterte regelmäßig mit runtime error 207 am viel zu kleinen Stack des 80x87 (8 Ebenen und Borland brachte es nicht auf die Reihe, das über den normalen Stack abzuwickeln). Tja. Und dann kam der Tag, als ich mein Login für die dicken UNIX-Hobel (RS6000 mit AIX) bekam. Da gabs kein Pascal (mit oder ohne "Turbo"). Da gabs C. OK, C war anders. Der Compiler langsam. Der Debugger eine Zumutung (verglichen mit TDB). Aber ich konnte z.B. ein 1MB großes Array anlegen. Und flott waren die Kisten auch. Und noch etwas später installierte ich mein erstes Linux (Kernel 0.97.irgendwas). Da gabs auch kein Pascal. Dafür einen super C compiler. Und die Programme waren für Linux und AIX praktisch gleich. Und wohin ich auch kam und was ich mir ansah - überall gab es C. Turbo Pascal hingegen nur für x86 und DOS/Windows. Auch als dann in der PC-Welt die DOS-Extender den Durchbruch schafften und das flat memory model die unsägliche Segmentierung killte - gabs das nur für C. Langer Rede kurzer Sinn: Pascal gabs schlicht nicht auf den von mir präferierten Systemen. Und da C praktisch gleichwertig war, bin ich halt zu C gewechselt. Und bis Borland (die dann schon anders hießen) es geschnallt hatten, daß sie sich mit ihrer nur-eine-Plattform Strategie selbst in den Fuß schießen, war es zu spät. XL
Axel Schwenke schrieb: > Pascal gabs Das stimmt. "Pascal vs C" ist eigentlich wie "Latein vs Englisch" Es gibt noch ein paar wenige, die Latein (Pascal) sprechen, aber mit Englisch (C) kommt man weltweit besser zurecht. Und für Englisch (C) finde ich jederzeit einen guten Übersetzer (Compiler) in die jeweilige Landessprache (Zielplattform). Welche Sprache ist also die nützlichere?
Folgender Text beinhaltet keine Wertung über bessere Eignung von C oder Pascal! Bernd K. schrieb: > http://www.bernd-leitenberger.de/pascal-und-c.shtml Also ich weiß nicht. Ich hab ein paar Absätze überflogen. die meisten Argumente, warum C nicht so toll ist, waren nach dem Motto "C macht es anders als Pascal, deshalb ist es doof". Manche Argumente sind einfach falsch: > In C sind Strings Zeiger auf eine Zeichentabelle. > Alles, worauf sie zeigen, wird als Zeichentabelle interpretiert > (auch wenn es keine ist). > Die Länge ist so dynamisch und das Ende wird durch das > Zeichen 0 festgelegt. Zudem unterstellt der Autor Kerninghan, er hätte Pascal nicht verstanden. Schon im ersten Beispiel zeigt er Autor, dass für ihn bei C das selbe gilt und dass er selbst von C auch nicht viel Erfahrung zu haben scheint:
1 | char * StringToUpper(char * zeile) |
2 | {
|
3 | char * temp; |
4 | int i; |
5 | int p = strlen(zeile); |
6 | temp = (char *) malloc(p); |
7 | for (i=0; zeile[i]!=0 && i<256; i++) |
8 | if (zeile[i]>='a' && zeile[i]<='z') |
9 | temp[i]=(char) zeile[i]-32; else temp[i]=zeile[i]; |
10 | temp[i]=0; |
11 | return temp; |
12 | }
|
Sowas würde nur ein absoluter C-Anfänger schreiben. Zumal sie für Strings mit Länge >=256 gar nicht funktioniert. Sorry, aber den Autor kann man nicht ernst nehmen. Und ja, ich mag Delphi und finde einige Sprachfeatures sehr interessant, zB die Properties. Sowas würde ich mir für C++ wünschen, anstatt dieser dummen expliziten Getter und Setter Methoden.
Für mich war immer die Möglichckeit jeden Opcode zu generieren entscheidend,volle Zustandskotrolle inclusive der Möglichkeit eigene Funktionen in assembler (möglichst inline) einzubinden eine wichtiges Argument. So kam ich von ASM über Basic Pascal Forth letztlich auch bei C an wobei ich gern möglichst nah an den basis funktionen bleibe und Klassen und unüberschtlichen (schlecht dokumentierten) Bibliotheksfunktionen möglichst meide, außer ich habe sie selbst verzapft. ;) Namaste
Oh mann, je länger man da drüberfliegt, desto mehr unsinn findet man: > Unions > gibt es nur in C. > Es sind Bitfelder mit denen man die einzelnen > Bits eines Bytes ansprechen kann. oder > Arrays > Arrays sind in Pascal zuerst einmal statisch, während man > in C Arrays als Zeiger auf Speicherbereiche aufpasst, > die man als Arrays interpretiert. oder > static ist einmal eine lokale Variable auf dem Heap [wirklich?] immerhin scheint der Autor hier zuzugeben, dass er eigentlich überhaupt keine Ahnung von dem hat, über das er hier schreibt. sorry, aber wenn man keine Ahnung hat, sollte man einfach nicht so einen Dummen Artikel schreiben. Edit: mir fällt gerade auf, die Stringfunktion oben funktioniert überhaupt nicht und schreibt lustig quer in den Speicher.
Lothar Miller schrieb: > "Pascal vs C" ist eigentlich wie "Latein vs Englisch" In vinum veritas Interessant ist schon die Diskussion... wenn man bedenkt, das es eigentlich um PIC's geht und ein Free-Pascal. Wow, Delphi Respekt. C++ war auch schon im Gespräch, Forth. Also, sollte mal der Tag kommen, wo mit VB oder Delphi ein ATMEL gefüttert wird: ich bin dabei. Ich schätze aber, das ich vermutlich vorher perfekt C spreche. Und jetzt gönn ich mir nach einem arbeitsreichen Tag ein Gläschen von dem edlen Roten.... Gruß oldmax
Nun ja, mit Pascal kann man einen STM32 proggen (Cortex-M3). Dennoch würde ich es nie machen. Alleine schon deshalb, weil ST die Header Dateien zur Peripherie nur für C liefert. Hingegen PC Programme schreibe ich lieber in Pascal (Lazarus). Irgendwie komme ich da viel schneller zum Ziel als mit C++, und ja, ich finde das in Pascal geschriebene Programm etwas übersichtlicher als der C-Code. (Siehe mein Programm EleLa, in Lazarus geschrieben, kompiliert für Win32/64 und Linux32/64.) Ich würde für Mikrocontroller niemals Pascal nehmen, denn Codevorlagen und Infos sind im WWW alle samt (meistens) in C. Oder bei Fragen im Forum für Mikrocontroller besteht auch eine deutlich höhere Chance einer richtigen Antwort, wenn ich in C progge. Auch portieren von Code zu einem anderen Controller (AVR>ARM>PIC) ist bei C einfacher. Ich mag beide Sprachen, beide haben Vor- und Nachteile. Ich meine C ist etwas für Mikrocontroller um möglichst Hardware nah zu proggen, Pascal eher was für PC's mit GUI und Tastatur/Mausbedienung und den vielen Controls in der Form. Bei Lazarus/Delphi ist das Formular und der Quelltext eine Einheit, die gegenseitig im IDE Editor richtig gut und intuitiv unterstützt werden. Wenn es C nicht gäbe und alle würden die Mikrocontroller in Pascal proggen, dann wäre das auch in Ordnung. Hingegen wenn es Pascal nicht gäbe würde ich schon was vermissen.
Ich hab zwar seit Jahren kein Pascal mehr gemacht, könnte mir aber vorstellen, dass diese gut strukturierte Sprache sich sehr für die Programmierung von µCs eignet. Gibt es einen Pascal-Compiler für AVRs (Tiny und Mega), der sinnvoll einsetzbar ist, oder sind das nur akademische Überlegungen?
Joachim Drechsel schrieb: > Vlad Tepesch schrieb: >> int p = strlen(zeile); > > Du hast recht - Anfängerfehler ;) in fast jeder Zeile dieses Code-Schnippsels ist ein Fehler, ganz zu schweigen von dem Designfehler, dass die Funktion Speicher vom Heap holt.
Oder die for-Schleife ohne {}, ich wusste garnicht,dass das geht. Da
fragt man sich, wie weit geht denn die Schleife. Da C sehr konsistent
ist, ist es klar, bis zum ';'. Aber Übersichtlich ist etwas anderes.
Man kann in C ziemlich viel Mist bauen, und man kann sich damit das
Leben schwer machen, aber niemand zwingt einen dazu, es ist
Eigenverantwortung. Es ist nichts für Leute, die immer eine überwachende
Instanz brauchen.
Zitat aus dem verlinkten Artikel: "Auch sonst sind [Anm.: in Pascal] selbst einfache Deklarationen dem Verstand des Nutzers angepasst. Was ist verständlicher "var temp: String" oder "char temp [256]"? Im ersten Fall kann man die Angabe fast wörtlich lesen. "Die Variable Temp ist ein String". Dagegen tauscht C die Definition um und deklariert den Variablentyp zuerst, und bei den Arrays wird es undurchsichtig, da die Dimension nicht am Variablentyp sondern am Name hängt." Unglücklich formuliert, klingt aber wie: PASCAL ist für Dumme :-)
Timm Thaler schrieb: > Gibt es einen Pascal-Compiler für AVRs (Tiny und Mega), der sinnvoll > einsetzbar ist, oder sind das nur akademische Überlegungen? http://www.e-lab.de/AVRco/index.html
Michael K. schrub:
>Unglücklich formuliert, klingt aber wie: PASCAL ist für Dumme :-)
Nein, Pascal ist für Leute gemacht worden, die sich nicht den Kopf mit
überflüssigen Verhaltensmaßregeln vollstopfen wollten.
Eine Programmiersprache ist ein Werkzeugkasten. Da will ich nicht erst
selbst Werkzeuge konstruieren müssen und an das Werkstück (den
Algorithmus
des Programmes) anpassen müssen.
C ist ein Sammelsurium aus einzelnen Nüssen, Bits und Inbusschlüsseln
-aber die Knarre fehlt.
MfG Paul
Paul Baumann schrieb: > aber die Knarre fehlt. aber ich dachte mit genau der schießt man sich bei C super einfach wahlweise den eigenen Fuß oder das Knie. Ich denke die Sinnlosigkeit der Diskussion, was ist besser ist, wird nur noch von dem verlinkten Artikel übertroffen. Der ist einfach einseitig und unfundiert, bzw einfach falsch. die hingegen hat einen waren Kern und regt zum Schmunzeln an. http://www.henning-thielemann.de/CHater.html
Sehe ich es nur nicht, oder wurde dieser Text http://www.leo.org/information/freizeit/fun/pascal.html tatsächlich noch nicht verlinkt?
Hundt schrieb: > Ich habe als Schüler ein Pascal-Programm geschrieben um meine > Lateinvokabeln zu trainieren. > > Ich musste dann das Programm in zwei Programme aufteilen, weil er in > einem Programm nicht genug CASE-Fälle bearbeiten kann. > > Ich habe das Programm mit CASE-Fällen geschrieben. LoL, weil Du nicht weißt wie man das Problem richtig löst ist die Sprache scheiße?
Paul Baumann schrieb: > C ist ein Sammelsurium aus einzelnen Nüssen, Bits und Inbusschlüsseln > -aber die Knarre fehlt. Da muss man eben mit den Fingern fummeln :-) Im Ernst: C hat so wenige Befehle, dass man sich das binnen einiger Tage oder maximal Wochen antun kann. Es kommt letztlich wie bei allen Programmiersprachen auf die Methoden an, die man kennt und applizieren kann und diese kosten die Zeit der Einarbeitung in die Programmierung. Die Offenheit und Erweiterbarkeit von C ist dabei das schlagende Argument gegenüber Pascal, wenn es um komplexere Funktionen sowie das Anpassen an die Aufgabe geht. Diese impliziert allerdings auch, dass es bei C infolge der mangelnden Rahmenvorgaben zu sehr vielen individuellen Sonderlösungen kommt, von denen nicht wenige suboptimal sind, da sie von den Kenntnissen des Entwickler abhängen. Besonders bei Echtzeitsystemen gibt es da viele Sonderlocken, die wegfallen und sich vereinfachen, wenn man in C++ arbeitet, wo viele Dinge vorgegeben und standardisiert sind. Auch wenn die Standardlösungen in C++ im Bezug auf Echtzeit- und Multitaskingfähigkeit dann objektiv gesehen nicht optimal sind, empfehlen sie sich dennoch im Hinblick auf Einarbeitung, Lesbarkeit, Wiederverwertbarkeit und Testbarkeit. Letztlich brauche ich persönlich keine zig Programmiersprachen und vor allem keine einfachen mehr, da heutige Anwendungen immer komplexer und grösser werden. Daher habe ich ASM, PASCAL und TURBOPASCAL gedropped. Umgekehrt habe ich nie C# angefangen, einzig JAVA und Python sind/wären interessant.
Hmm, ich bin ja nur Hobby-Anwender und momentan mit LunaAvr-Basic sehr zufrieden. Konnte sogar in kurzer Zeit LEDs anzünden ohne hier ständig nachzufragen ;o) Das mit dem PIC-Pascal finde ich sehr interessant, damit könnte ich mich zukünftig auch evtl. mit PICs näher beschäftigen. Natürlich sehe ich auch die Vorteile von C, gerade im professionellem Bereich. Da ich mich da aber nur oberflächlich damit beschäftigt habe, frage ich mich immer: Warum oft C empfohlen wird, dagegen aber Assembler nur selten erwähnt wird?
Klaus I. schrieb: > Warum oft C empfohlen wird, dagegen aber Assembler nur selten erwähnt > wird? Weil Assemblerprogrammierung zu fehlerträchtig, zu schlecht pflegbar und zu teuer für professionelle Anwendung ist und weil heutige Compiler meist besseren Code erzeugen, als es ein durchschnittlicher ASM-Programmierer hinbekommt.
oldmax schrieb: > aber mir ist es genauso wie den anderen 99,9% der Programmierer wichtig, > mein Program zu verstehen. Das es ein anderer lesen kann ist erst einmal > zweitrangig. Und nebenbei: wer eine Aufgabe nicht klar in ein > xbeliebiges Programm umsetzen kann, der braucht auch nicht irgendeine > Sprache favorisieren. Leider tauchen von diesen Superstars immer mal welche in "echten" Firmen auf und verursachen dort sehr hohe Kosten wenn Softwareänderungen anstehen, wenn sie mal krank werden oder die Firma verlassen.
Hi Wenn ein Programmierer sich in Gedankengänge anderer einarbeiten muss, sind das immer Kosten. Ich schrieb übrigends auch, das es Firmen gibt, deren Bedingungen bei Einstellung eine vorgegebene Sprache ist. Sorry, es wird lächerlich ständig z u behaupten, die Weltreligion heißt C und alles andere ist Heidentum. Es ist doch unstrittig, das C seine Verbreitung und auch Daseínsberechtigung hat, doch die Lesbarkeit ist in der Regel erst durch richtige Kommentierung gegeben. Sprachen wie BAsic und Pascal laufen zwar unter "selbsterklärend" aber warum eine Aufgabe in einer bestimten Art gelöst ist, wird erst durch eine entsprechende Kommentierung klar. Assembler ist, wenn es gut dokumentiert ist, auch nicht schlechter Lesbar wie C. Kommt natürlich auch auf den Programmierer an, wie tief er drin steckt. Und das gilt für jede Sprache. Wenn ich täglich mit C zu tun hätte, wären das für mich auch keine abstrakten Satzgebilde. Ich kann kein C, aber deshalb mache ich es doch nicht schlecht. Schließlich ist dieser Umstand meiner Faulheit zu verdanken. Aber ich bläh mich jetzt nicht wie ein Frosch auf und klopf mir auf die Schulter, weil ich so ein guter Assemblierer bin. Oder in den Steuerungssprachen meine Welt habe. Je mehr auf einer Programmiersprache beharrt wird, umso mehr ist dies für mich einZeichen, das die von euch erwünschte Beachtung doch auf einem sehr begrenzten Blickwinkel basiert. Die Welt ist eben nicht schwarzweiß, sie ist bunt. Gruß oldmax
Martin Vogel schrieb: > Assembler ist, wenn es gut dokumentiert ist, auch nicht schlechter > Lesbar wie C. Nur liest man dann nicht den ASM-Code, sondern die Kommentare - das Programm muß also quasi zweimal geschrieben werden: einmal so, daß der Assembler was damit anfangen kann und dann nochmal auf Deutsch, Englisch, oder was auch immer. Diese Redundanz erweist sich dann spätestens beim ersten großen Umbau als Fatal und aus dem Mist, der dann dort steht, wird keiner mehr klug und das Programm macht sowieso was ganz anderes...
Eben, darum sind gute Programme in weiten teilen selbsterklärend bzw. dokumentierend. Dennoch braucht man Kommentare im richtigen Mass an der richtigen Stelle. Strukturierte Programmierung auf Mikrocontrollern
Hi Uhu Uhuhu schrieb: > Martin Vogel schrieb: >> Assembler ist, wenn es gut dokumentiert ist, auch nicht schlechter >> Lesbar wie C. > > Nur liest man dann nicht den ASM-Code, sondern die Kommentare - das > Programm muß also quasi zweimal geschrieben werden: einmal so, daß der > Assembler was damit anfangen kann und dann nochmal auf Deutsch, > Englisch, oder was auch immer. > > Diese Redundanz erweist sich dann spätestens beim ersten großen Umbau > als Fatal und aus dem Mist, der dann dort steht, wird keiner mehr klug > und das Programm macht sowieso was ganz anderes... Wer sagt denn, das eine Dokumentation ausschließlich aus Kommentaren besteht? Und wenn ein Programm zweimal geschrieben werden muss, ist die erste Version sowieso Schrott. So wie du in C die Zeilen liest, list ein mit Assembler vertrauter Programmierer eben Assembler. Und ja, manchmal muß man ein wenig nachdenken, um sich über den ein oder anderen Sinn ein Bild zu machen. Aber das trifft auf C genauso zu. Erzähl mir nicht, du durchschaust ein C Programm eines Kollegen sofort. Aber das ist auch völlig witzlos, denn es geht nicht darum, der Welt die einzig wahre Programmierung zu verklickern, sondern eben auch zu verstehen, das es doch tatsächlich Typen gibt, die sich in einer anderen Sprache üben. Ich brauche keinen Vergleich X mit Y. Wozu? Warum soll ich einer Gemeinde angehören? Warum soll ich Andersdenkende missachten? Warum soll ich etwas schlechtreden, weil es etwas meinen Horizont übersteigt. C ist doch OK, wenn man es kann und damit seine Aufgaben erledigt. Warum zitierst du einen Satz aus dem Zusammenhang gezogen und packst einen nicht grad professionellen Kommentar dazu? Versuch dir mal die Antwort selbst zu geben.. viel Spaß dabei. Gruß oldmax
Martin Vogel schrieb: > Wer sagt denn, das eine Dokumentation ausschließlich aus Kommentaren > besteht? In Assembler? Na das will ich sehen... > So wie du in C die Zeilen liest, list ein > mit Assembler vertrauter Programmierer eben Assembler. Ach ja? Ich habe lange genug beruflich ASM programmiert, um zu wissen, daß es nicht so ist. Nehmen wir als Beispiel eine etwas kompliziertere mathematische Formel. Bis die ein ASM-Programmierer aus dem ASM-Quelltext extrahiert hat, hat der Hochsprachler schon die nächsten 50 Formeln überprüft. > Aber das trifft auf C genauso zu. Erzähl mir nicht, du > durchschaust ein C Programm eines Kollegen sofort. Wir brauchen uns da garnicht auf C einzuschießen, denn dieselben Argumente gelten für alle Hochsprachen: - ASM ist an der Funktionsweise von Prozessoren orientiert - ein ASM-Befehl ist selten mehr, als ein Maschinenbefehl - Der menschliche Verstand funktioniert völlig anders, als ein Prozessor - Hochsprachen sind Vehikel, die aus formalisiert formulierten menschlichen Gedanken ein Maschinenprogramm machen, das äquivalent zur Formulierung in der Hochsprache ist. > Erzähl mir nicht, du > durchschaust ein C Programm eines Kollegen sofort. Aber wenn ein erfahrener Programmierer eine Datenstruktur, wie z.B. ein Dictionary sieht, dann weiß er sofort, was da gespielt wird. Das entsprechende Konstrukt in ASM kann er nur anhand von Kommentaren als das erkennen, was es - hoffentlich - ist und bis er das begriffen hat, ist der Hochsprachler schon 20 Seiten weiter - im Hochsprach-Text wohlgemerkt. Wenn man deine Argumentationsweise für ASM auf Verkehrsmittel übertragen würde, käme ungefähr sowas raus: - Eisenbahnen braucht man eigentlich nicht - Ochsenkarren tuns auch - Autos sind völlig überflüssig - man kann auch laufen Schwachsinn? Ja klar...
Ich habe das Gefühl, alles läuft hier auf einen Schwanzvergleich hinaus. Dabei ist doch der Vergleich - Pascal gegen C - Assembler gegen C schon entschieden :-) http://www.social-media-schwanzvergleich.de/
Paul Baumann schrieb: > Michael K. schrub: >>Unglücklich formuliert, klingt aber wie: PASCAL ist für Dumme :-) > > Nein, Pascal ist für Leute gemacht worden, die sich nicht den Kopf mit > überflüssigen Verhaltensmaßregeln vollstopfen wollten.[...] Ich wollte eigtl. nur die "sachliche" Diskussion auflockern - konnte ja nicht ahnen, dass sowas (selbst am Freitag) ernst genommen wird... Zum Thema: Unabhängig von der Programmiersprache gibt es überall Spezis, die duch Ihren Stil und exzessiven Einsatz irgendwelcher Features einen Quelltext unlesbar machen können. Letztendlich hat auch in Programmiersprachen jeder seinen "Dialekt", den ein anderer erstmal verstehen muss.
Hi > Letztendlich hat auch in Programmiersprachen jeder seinen "Dialekt", den > ein anderer erstmal verstehen muss. Der versteht mich.... Gruß oldmax
Peter II schrieb: > Wenn er hat zwar Ahnung von vielen dingen aber nicht von C. Und wie soll > er das etwas sachliches über C schreiben? Das habe ich mich dabei auch gefragt. Außerdem unterstellt er (zumindest unterschwellig), dass C sich nach Pascal entwickelt hätte und bewusst anders sein wollte. In Wirklichkeit haben sich beide Sprachen ziemlich nebenher entwickelt (Wikipedia nennt für Pascal 1972, Unix und C sind Anfang der 1970er Jahre entstanden).
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.