Haltet ihr Pascal für eine sterbende Sprache?

[Michl]

-

[m.fuchs]

Ich habe die Uncicode-Diskussion mal in einen eigenen Thread verschoben. Dazu bitte hier (viewtopic.php?f=9&t=10413&start=30) weiterdiskutieren.

Hier geht es dann weiter mit dem Ursprungsthema.

[mschnell]

Ich habe die Uncicode-Diskussion mal in einen eigenen Thread verschoben.

Danke !
Im Prinzip gut, es bleibt aber festzuhalten dass die Uncicode-Diskussion nicht "off-tpic" war, sondern sich die Problematik tatsächlich für diverse Ein- und Umsteiger und für bestimmte Aufgaben als Hemmschuh erweisen kann.

-Michael

[FPK]

Für FPC ist es wesentlicher wichtiger bestehende Nutzer zu halten und ihren Code nicht kaputtzumachen als irgendwelche Trends/Ideen/Hypes nachzurennen, nur weil jemand dann neue Nutzer verspricht (!).

[mschnell]

Unter diesem Aspekt hätte man Unicode nicht einführen sollen.

Ich weiß aber nicht ob das ein sinnvolles Vorgehen gewesen wäre.

-Michael

[creed steiger]

Die Unicode Einführung war einfach ein Erfordernis.

SuSE zum Beispiel hatte Unicode seit 2004!

Da war schon abzusehen das daran kein Weg vorbeigeht.
Davon abgesehen ist Unicode gut dokumentiert und zertifiziert.
https://www.cl.cam.ac.uk/~mgk25/unicode.html

Von daher geht kein Weg dran vorbei, über die Implementierung kann man sicher streiten, aber einen Tod muß man sterben.

Das die BorEmbawasauchimmer Macher in ihrer schnarchnasigen Blase da nicht grad die Fackel der intelligent Entwicklung hochhalten steht natürlich auf einem anderem Blatt.

Wenn man die aktuelle Entwicklung von Delphi anschaut merkt man ja auch das die klare Linie fehlt (App Method,kostenlose Version ja/nein,Ark Einführung, Personalpolitik usw usf.)

[Bitschubser]

Die Unicode Einführung war einfach ein Erfordernis.

Dem kann ich nur zustimmen.

Von daher geht kein Weg dran vorbei, über die Implementierung kann man sicher streiten, aber einen Tod muß man sterben.

In der Tat. Ich bin aber immer noch der Meinung, dass ein Ding was immer noch String heißt aber plötzlich Elemente hat die nicht (immer) ein Byte breit sind keine gute Idee war.
Man hätte das ganze meiner Meinung nach komplett parallel aufziehen sollen, und sich dabei die "Magig" komplett sparen.
Und die "Delphi-Kompatibilität" liefert hier auch keinerlei Entschuldigung - schließlich sind die Implementierungen von "string" ja jetzt unterschiedlich.

Das die BorEmbawasauchimmer Macher in ihrer schnarchnasigen Blase da nicht grad die Fackel der intelligent Entwicklung hochhalten steht natürlich auf einem anderem Blatt.
Wenn man die aktuelle Entwicklung von Delphi anschaut merkt man ja auch das die klare Linie fehlt (App Method,kostenlose Version ja/nein,Ark Einführung, Personalpolitik usw usf.)

Wenn das alles wär...
Der schon seit vielen Jahren quasi nicht existente Support für zahlende Kunden, Einträge im Bugtracker im schulpflichtigen Alter...
Wenigstens geht überhaupt noch einer an's Telefon wenn wg. erneuertem Viertrechner der Installationszähler mal wieder übergelaufen ist.

[wp_xyz]

In der Tat. Ich bin aber immer noch der Meinung, dass ein Ding was immer noch String heißt aber plötzlich Elemente hat die nicht (immer) ein Byte breit sind keine gute Idee war.

Hier widersprichtst du dich: Einerseits willst du Unicode, aber andererseits forderst du, dass String-Elemente nur 1 Byte breit sein dürfen. Mit dieser Forderung wirst in ein- und demselben String nie eine mathematische Formel mit griechischen Buchstaben zusammen mit unseren Schriftzeichen darstellen können; 256 Zeichen reichen halt nicht aus. Wenn man einmal die geistige Hürde übersprungen hat und akzeptiert, dass 1 Zeichen eben nicht immer 1 Byte sein muss, ist UTF8 ganz einfach!

[Bitschubser]

In der Tat. Ich bin aber immer noch der Meinung, dass ein Ding was immer noch String heißt aber plötzlich Elemente hat die nicht (immer) ein Byte breit sind keine gute Idee war.

Hier widersprichtst du dich: Einerseits willst du Unicode, aber andererseits forderst du, dass String-Elemente nur 1 Byte breit sein dürfen. Mit dieser Forderung wirst in ein- und demselben String nie eine mathematische Formel mit griechischen Buchstaben zusammen mit unseren Schriftzeichen darstellen können; 256 Zeichen reichen halt nicht aus. Wenn man einmal die geistige Hürde übersprungen hat und akzeptiert, dass 1 Zeichen eben nicht immer 1 Byte sein muss, ist UTF8 ganz einfach!

Nein, ich sehe da keinen Widerspruch.
Ich hab ja nicht geschrieben, dass alle neueingeführten string-artigen Datentypen immer nur ein Byte pro Zeichen haben sollen.
Ich hätte mir nur gewünscht, man hätte den seit Jahrzehnten verwendeten "String" String sein lassen und den neuen Datentyp (mit "manchmal mehr als einem"/2/4-Bytes pro Zeichen) anders genannt - "UnicodeString"/"UString"/was auch immer.
Wobei man über die "manchmal mehr als ein"/2/4-Bytes pro Zeichen noch mal separat diskutieren kann - hat aber alles Vor- un Nachteile.
Bloss den String einfach umzutaufen, das hat nur Nachteile...

[mschnell]

Ich habe einen (noch nicht 100% ausgereiften) Vorschlag wie man es mit Strings mit variabler Codierung (z.B ASCII, ANSI, UTF-8, UTF16, UTF32, RAW 8, 16, 32 und 64 Bit) und variabler Wortlänge) bei großer User-Code Kompatibilität zu Delphi 7, vor-Unicode Lazarus und Delphi XE machen könnte (mit TStrings mit variabler Codierung) im (englischen) Wiki ausgeführt. Es ist aber nicht zu erwarten, dass die Compiler-Entwicklung Lust oder Zeit dazu haben, das zu implementieren und tu testen.

-Michael

[grau]

Wir programmieren als mittelständische Firma seit 2 Jahrzehnten mit ObjectPascal (Delphi- und jetzt Lazarus). Sterben tut da prinzipiell nichts, wenn ein FPC/Lazarus-basierendes Softwareprodukt erstmal eine gewisse Größe erreicht hat- dann muss man mit der Sprache weiterarbeiten. Das Problem liegt eher darin, dass die Mehrheit der Entwickler in C++/C#/.net/Java und anderen modernen Sprachen arbeitet. Folglich muss Code oftmals erstmal nach ObjPascal umgeschrieben werden. Von der Mächtigkeit ist FPC-Pascal gegenüber Delphi-Pascal schon etwas besser geworden (generic und operator Modifier z.B.). Wenn man C++ betrachtet, fehlen aber noch definierbare Namespaces oder Objekt-Mehrfachvererbung in FPC. Ansonsten kann man m.E. auch schon sagen, dass Pascal eine relativ Syntax-sichere Sprache ist, während C/C++ in dem Punkt viele Fehlerquellen aufweisen (z.B. Pointer-Referenzierung/Dereferenzierung sowie Header-Files in C/C++).

Pascal ist eine Lehr- und Lernsprache und für den Einstieg ideal geeignet. Und auch der Fortgeschrittene/Profi, der für die Entwicklung von kleinen/mittelgroßen Desktop-Anwendungen auf FPC setzt, ist sicherlich nicht schlecht beraten- auch in Hinblick auf die Hardware Multiplatform-Einsatzzwecke.
Dennoch sollte auch gesagt werden, dass FPC/Lazarus mit der Zeit gehen muss, um mit Konkurrenzsprachen- und IDEs mithalten zu könne - das gilt für alle Bereiche, die einen Kompiler/Interpreter+IDE tangieren: Syntax, Semantik, Pragmatik. Oder etwas konkreter ausgedrückt: Compiler (oder auch Interpreter-) Performance, Portabilität, Robustheit, Verbreitungsgrad, Hardware-Einsatzgebiete, Sicherheit, uvm.

Christian Grau

[Mathias]

Wenn man C++ betrachtet, fehlen aber noch definierbare Namespaces

Löst das Pascal nicht mit "with abc do" ?

[FPK]

In der Tat. Ich bin aber immer noch der Meinung, dass ein Ding was immer noch String heißt aber plötzlich Elemente hat die nicht (immer) ein Byte breit sind keine gute Idee war.

Hier widersprichtst du dich: Einerseits willst du Unicode, aber andererseits forderst du, dass String-Elemente nur 1 Byte breit sein dürfen. Mit dieser Forderung wirst in ein- und demselben String nie eine mathematische Formel mit griechischen Buchstaben zusammen mit unseren Schriftzeichen darstellen können; 256 Zeichen reichen halt nicht aus. Wenn man einmal die geistige Hürde übersprungen hat und akzeptiert, dass 1 Zeichen eben nicht immer 1 Byte sein muss, ist UTF8 ganz einfach!

Nein, ich sehe da keinen Widerspruch.
Ich hab ja nicht geschrieben, dass alle neueingeführten string-artigen Datentypen immer nur ein Byte pro Zeichen haben sollen.
Ich hätte mir nur gewünscht, man hätte den seit Jahrzehnten verwendeten "String" String sein lassen und den neuen Datentyp (mit "manchmal mehr als einem"/2/4-Bytes pro Zeichen) anders

Auf einem Linux mit UTF-8 als Codepage war die Codepage eines Strings schon immer (!) UTF-8 in FPC. Die meisten Programmierer haben das aber ignoriert.

[creed steiger]

Oder etwas konkreter ausgedrückt: Compiler (oder auch Interpreter-) Performance, Portabilität, Robustheit, Verbreitungsgrad, Hardware-Einsatzgebiete, Sicherheit, uvm.

Christian Grau

Das seh ich schon viele Punkte bei FPC/Lazarus erfüllt.
Ein Schwachpunkt der mir schmerzlich einfällt ist der Debugger, allerdings unter Freiwilligen bei einem OpenSource Projekt da eine Spezialisten zu finden ist halt auch schwer.

[Michl]

Ein Schwachpunkt der mir schmerzlich einfällt ist der Debugger

Ich bin ja Quereinsteiger, was programmieren angeht. Daher bin ich nicht verwöhnt, was andere Entwicklungsumgebungen angeht. Allerdings vertehe ich dadurch auch nicht, was beim debuggen vermisst wird. Zumindest unter Windows mit Dwarf2 kompilierte Anwendungen verbergen mir keine Bezeichner bzw. deren Werte.

Oft reicht mir der Hint, der beim debuggen unter der Maus gezeigt wird. Wenn nicht, dann hilft mir eigentlich immer <Strg> + <F7>. Sogar das modifizieren von Properties geht beim debuggen. Bisher einziges Manko, was mir selbst aufgefallen ist, daß Methodenpointer nicht aufgelöst werden können.

Daher meine neugierige und ernst gemeinte Frage: Was können Delphi bzw. andere Tools besser darstellen und wie?