Warum andere Programmiersprachen neben Pascal?

[Jay]

Hallo,

ja, meine Frage ist eine Provokation. Ich habe sie gestellt, weil ich u.a. wissen wollte, was man mit anderen Programmiersprachen mehr/besser kann als mit (Object-) Pascal

Bisher ist mir nämlich nichts aufgefallen, was ich speziell bei Object-Pascal (Lazarus, Delphi) vermisse. Alles ist z.B. durch Komponenten/Units erweiter-/ergänzbar. Wenn man keine passenden Komponenten findet, kann man natürlich auch selber welche schreiben

Aber mal im Ernst, wozu noch C/C++, Java und Co? Spezielle Programmiersprachen mal ausgenommen (z.B. Script-, SPS-, Mathematische u.s.w.).

Ich bin mal auf eure Antworten gespannt

Okay, mit C/C++ habe ich persönlich schlechte Erfahrung gemacht, weil mir diese Sprachen zu unübersichtlich und kompliziert sind. Wozu kompliziert, wenns auch einfach geht? Vielleicht ist Pascal auf diesem Sektor einfach noch nicht sehr bekannt/ausgereift (z.B. bei der Betriebssystemprogrammierung, wobei es hier auch schon Ansätze gibt - z.B. http://schutsch.de.vu" onclick="window.open(this.href);return false; - eine Seite von einem guten Chat-Kumpel)...

Mal abgesehen davon: mit Object-Pascal kann man auch sehr komplexe Programme schreiben, die der komplexen/komplizierten Syntax von C/C++ weitaus überlegen sind.


Gruß

Jay

[RSE]

Soweit ich weiß, ist Pascal wesentlich älter als C. Allerdings wurde Pascal nicht so gepflegt und weiterentwickelt wie C und C++. Bestimmt erinnert sich noch jeder an TurboPascal. TP baute mit den letzten Versionen (6 und 7) erste Ansätze von Objektorientierung in die Sprache ein. Mit Delphi wurde die Sprache von Borland dann weiter ausgebaut. FreePascal hat dann in den letzten Jahren weitere Sprachkonstrukte von C++ übernommen. Durch die nicht so gute Optimierung des Compilates (Effizienz des Codes, den der Compiler ausspuckt) durch Borland und das Fehlen mancher Sprachkonstrukte ist ObjektPascal in den vergangen Jahren gegenüber C/C++ ins Abseits geraten. Meines Erachtens sind diese Nachteile inzwischen mit Freepascal der Vergangenheit angehörig. Durch die Plattformunabhängigkeit von Lazarus hat es in meinen Augen sogar Vorteile gegenüber der Konkurrenz. Vielleicht gibt es ja einen zweiten Frühling für ObjectPascal, wer weiß...

Java ist dabei kein direkter Konkurrent von ObjectPascal und C/C++, da Java ja keinen nativen Code erzeugt, sondern in einer VM läuft.

[Jay]

Sehe ich genauso. Es wurden in der Vergangenheit bei der Weiterentwicklung von Pascal viele Fehler gemacht, die leider erst verspätet wieder gut gemacht wurden. Und dass Java nur auf einer VM läuft, sehe ich als Nachteil.

[RSE]

...dass Java nur auf einer VM läuft, sehe ich als Nachteil.

Naja, Nachteil würde ich nicht sagen, es hat Nachteile (z.B. Performance), aber auch Vorteile (z.B. Portabilität). Es ist eben "anders".

[baba]

Soweit ich weiß, ist Pascal wesentlich älter als C.

Pascal, Niklaus Wirth, ETH-Zürich, 1972
C, Dennis Ritchie, Bell Labs, 1972

TP baute mit den letzten Versionen (6 und 7) erste Ansätze von Objektorientierung in die Sprache ein.

Ab Version 5.5

Pascal ist mir lieber, da es eine strukturierte Programmierung erfordert. Unter C kann man am Morgen ein Programm schreiben, welches man am Abend nicht mehr versteht. Jeder der große Programme schreibt und diese zu einem späteren Zeitpunkt ändern oder ergänzen muß, wird eine strukturierte, ordentliche Sprache zu schätzen wissen.

Grundsätzlich ist aber die Programmiersprache immer auch von der Anwendung abhängig - wer möchte schon ein Betriebssystem in Lisp, Cobol oder Fortran schreiben? Hingegen wird ein Bänker auch heute noch meistens zu Cobol greifen.

Gruß
Baba.

Es wurden in der Vergangenheit bei der Weiterentwicklung von Pascal viele Fehler gemacht,

Welche? DotNet in Delphi? Delphi zu Microsoftlastig?

[Jay]

Welche? DotNet in Delphi? Delphi zu Microsoftlastig?

Unter anderem. Gott sei dank wurde diese Barriere durchbrochen

[RSE]

Pascal, Niklaus Wirth, ETH-Zürich, 1972
C, Dennis Ritchie, Bell Labs, 1972

*mist* doch verschätzt... hätte mir doch die Zeit nehmen sollen zu googlen... Danke für die Aufklärung!

[hendy]

aber mit c kann man maschienen programmieren, also mit sensoren und so (glaub ich, belehrt mich eines besseren)

[Hitman]

aber mit c kann man maschienen programmieren, also mit sensoren und so (glaub ich, belehrt mich eines besseren)

C ist ja nur ein etwas schöneres Assembler. Damit kann man also schon recht maschinennah arbeiten. Aber mit großer Macht kommt große Verantwortung
FPC kann man aber auch relativ gut für Embedded Systeme nutzen ... häufig wird herstellerseitig aber halt ein C Compiler geliefert, wodurch man sich um den FPC Support selbst kümmern müsste (was aber auch nich sooo schwierig ist ... Zeit brauchts trotzdem).

[RSE]

An dieser Stelle ist einfach der Große (weit verbreitete) mächtig. Der Hersteller wird 1. nur eine Sprache unterstützen und 2. die wählen, die am weitesten verbreitet ist, und das ist in diesem Fall nun mal C. Oder es wird ein Device "zum Spielen" extra hergestellt, um eine Programmiersprache zu pushen. Ein solches ist z.B. der Sun Spot, den man mit Java programmiert.

Ein Device mit einer anderen als der vorgesehenen Programmiersprache zu programmieren ist in meinen Augen wohl nur in den allerseltensten Fällen möglich, da solche Geräte ja kaum einen einheitlichen Maschinencode haben (oder irre ich mich?), der nicht weiter dokumentiert ist, so dass man an den mitgelieferten Compiler gebunden ist.

[Hitman]

Ein Device mit einer anderen als der vorgesehenen Programmiersprache zu programmieren ist in meinen Augen wohl nur in den allerseltensten Fällen möglich, da solche Geräte ja kaum einen einheitlichen Maschinencode haben (oder irre ich mich?), der nicht weiter dokumentiert ist, so dass man an den mitgelieferten Compiler gebunden ist.

Wobei genau hier natürlich Java interessant wird. Ein direkt auf Java getrimmter Prozessor kann sehr effizient damit umgehen (im Prinzip ist das ganze Gerät ja dann die "Java VM"). Der Vorteil für die Hersteller ist, dass sie "nur" die JRE an ihr Gerät anpassen müssen, alle anderen Entwickler können sich dann auf die bestehenden Java Klassen berufen (natürlich nicht alle, da das Gerät sicher seine Einschränkungen hat). Aber alles in allem ist das für alle Beteiligten bequemer. Ich vermute aber, der Haken werden Lizenzgebühren sein (kann mir nicht vorstellen, dass die nötige Technik nicht patentiert ist, um Java in Embedded Devices einzubauen).

[Bora4d]

C und C++ sind standardisierte Industrie-Sprachen Pascal nicht. Naja Pascal hat auch ein Iso-Standard aber es ist immer noch nicht von herstellern vollständig umgesetzt. Im standard Pascal gibts nicht mal Zeichen (string). Was wir als Pascal kennen ist meistens von Borland mit TP-Reihe, später mit Delphi implementiert bzw. ergänzt worden. Viele Programmier haben damals direkt bei C/C++ angefangen weil sie von Lehrbüchern gelesen haben, dass Pascal Lehrsprache und sehr eingeschränkt ist. Unter anderem die Industrie hat mehr auf C und C++ gesetzt und Normen und Standards für diese Sprache gesetzt.
Ich bin seit TP 5.5 dabei und bin begeistert von dieser Sprache. Ich habe kurzzeitig in den 90ern C und C++ benutzt. C++ finde ich ätzend. Ich sehe zwischen C und Pascal keinen Unterschied außer einige kleinigkeiten wie Variablen die man in C zwischen den Zeilen definieren kann ...
In C++ habe ich nie verstanden wofür die berühmten Templates sein sollen. Ich hatte damals weiterhin normale Listen verwendet. NIcht zu vergessen sind für eine Klasse "erzwungene" mehrere Copy-Konstruktoren und Verleichsoperatoren..
In finde dass Pascal langsam zu P++ wird. Ich habe neulich Quelltexte für Delphi 2010 gesehen da waren Klassen als Unterklassen definiert. Blöde formulierung so ungefähr war es:

Code: Alles auswählen

type
 TKlasee = class
   TUnterclass = class
   end;
 end;

Ich glaube langsam wird es Zeit von schlecht kopierten P++ gleich zu C++ zu wechseln.
ja, schön war die Welt zu TP/TPW-Zeiten wenige typen wenige funktionen so das man alles im Kopf behalten konnte...

[RSE]

Ein direkt auf Java getrimmter Prozessor kann sehr effizient damit umgehen (im Prinzip ist das ganze Gerät ja dann die "Java VM").

Also unser Problem bei der Programmierung war, dass eine Zeitmessung zwar durch die Auflösung des Timers im Gerät sehr genau möglich gewesen wäre, aber durch die Eigenheiten von Java vereitelt wurde, da die Ereignis-Handler mit unregelmäßigem zeitlichen Versatz zum Ereignis aufgerufen wurden (Jitter). Ich kann die vermutete Ursache nicht mehr genau wiedergeben, da ich kein Java-Programmierer bin, aber diese Sache hat unser Vorhaben vereitelt. Das schlimmste: Sie ist sogar Sun bekannt, aber sie haben keine Lösung für dieses Problem. Mit einer systemnahen Programmiersprache wäre es nicht aufgetreten.

Übrigens: Es hat wohl mal einen Prozessor gegeben, der Java-Code nativ ausgeführt hat, aber gefloppt ist... so viel zur "nativen VM". Ich halte von der Programmierung von solchen Devices mit abstrahierten Programmiersprachen wie Java nichts.

[mschnell]

aber mit c kann man maschienen programmieren, also mit sensoren und so (glaub ich, belehrt mich eines besseren)

C gibt es für fast jede Prozessor-Hardware. Ich kenne kein Beispiel wo es nur Assembler und eine andere Hochsprache gibt.

Der große Vorteil von (ANSI-) C ist, dass man fast so Maschinen-nah programmieren kann wie mit Assembler, der größte Teil des Codes trotzdem nicht Hardware-Spezifisch ist.

-Michael

[Euklid]

Ich halte Pascal/OP für gleichwertig zu C oder C++. Pascal hat hier und da Vorteile gegenüber C, C hier und da gegenüber Pascal. C ist eben verbreiteter und hat dadurch Vorteile bezüglich der Verwendung verschiedener Prozessorarchitekturen. Pascal ist dagegen eine Sprache, die in meinen Augen sehr wenig Fehleranfällig ist - d.h. das Programmieren macht wenig Arbeit, da die Struktur der Sprache und die Umsetzung im FPC den Code übersichtlich und weniger anfällig für Speicherzugriffsfehler macht. Dennoch kenne ich Leute, die Treiber mit Pascal geschrieben haben - d.h. hardwarenahes Programmieren sollte mit Pascal ebenfalls möglich sein.

In der Summe bleibt es alles in allem wohl eine Geschmacksache, welche Sprache von den beiden man bevorzugt.

Mit Java-Anwendungen habe ich bisher recht unbefriedigende Erfahrungen gemacht. Java-Anwendungen, die ich regelmäßig verwende, sind Tracker und Geogebra. Im Vergleich zu anderen Anwendungen kommen die von mir verwendeten Java-Anwendungen recht träge vor. Auch sind die Java-Anwendungen nur unzureichend in die Oberfläche des jeweils verwendeten Betriebssystems integriert, was gewöhnungsbedürftig ist. Die Vorteile von Java sehe ich eher im Bereich der Web-Anwendungen.

Viele Grüße, Euklid