Haltet ihr Pascal für eine sterbende Sprache?

[mschnell]

So gesehen ist was das angeht .Net besser als Pascal.

Bitte nicht die Begriffe durcheinanderwerfen !!!
Es gibt z.B. Pascal für .NET ("Oxygen") und auch GDB für C . Vermutlich meinst Du also "native Code" vs "Framework execution".

Außerdem müsste man hier noch "managed" und "unmanaged" Code unterscheiden.

-Michael

[Mathias]

Du kannst gerne noch XP verwenden, aber wenn man ein System verwendet welches seit mehr als 2 Jahren keinen Support mehr erhält sollte man sich nicht über Kompatiblität beschweren
Wenn man Vista totschweigt und sagt dass 7 das nächste Windows an XP ist, dann hat man mit Windows 7 .Net 3.5 auf jeden Fall vorinstalliert.

Du kannst mir ja gerne ein Windows 7 oder 8 mit 32 Bit kaufen. Von diesen habe ich nur die 64Bit und diese laufen bei mir nicht in der VB.
Ich brauche Windows nur noch sehr selten, und dafür habe ich WinXP in der VB.

[Warf]

So gesehen ist was das angeht .Net besser als Pascal.

Bitte nicht die Begriffe durcheinanderwerfen !!!
Es gibt z.B. Pascal für .NET ("Oxygen") und auch GDB für C . Vermutlich meinst Du also "native Code" vs "Framework execution".

Außerdem müsste man hier noch "managed" und "unmanaged" Code unterscheiden.

-Michaer

Ja das ist mir schon klar, ich meine mit pascal nicht direkt die Sprache sondern fpc bzw. Delphi als Implementierung, hab das nur relativ schnell geschrieben in einer kurzen Pause, hatte nicht so viel Zeit, und ich denke es ist jedem klar was ich meine

Du kannst gerne noch XP verwenden, aber wenn man ein System verwendet welches seit mehr als 2 Jahren keinen Support mehr erhält sollte man sich nicht über Kompatiblität beschweren
Wenn man Vista totschweigt und sagt dass 7 das nächste Windows an XP ist, dann hat man mit Windows 7 .Net 3.5 auf jeden Fall vorinstalliert.

Du kannst mir ja gerne ein Windows 7 oder 8 mit 32 Bit kaufen. Von diesen habe ich nur die 64Bit und diese laufen bei mir nicht in der VB.
Ich brauche Windows nur noch sehr selten, und dafür habe ich WinXP in der VB.

Mir ist egal ob du xp verwendest oder nicht, doch wer ein System verwendet was nicht mehr supported wird sollte sich einfach nicht über Kompatibilität beschwerenden, wenn man so ein System verwendet sollte klar sein dass man Kompatibilitätsabstriche machen muss

Das ist kompletter Müll, du vergleichst grade .Net DLL's mit Lazarus source code Packages. Wenn du in Lazarus eine DLL verwendest (z.B. Bass) muss diese auch auf dem Zielrechner installiert sein, ....

Nein, nur anwesend.

Selbes gilt für .Net DLL's, von der Benutzung unterscheiden sie sich kaum von nativen DLL's

[Aliobaba]

Hallo,

wenn ich sehe,
wie schwierige es (für mich als rel. Laie) ist, mit dem "Qt-Creator" auch nur einen Klick zu programmieren ("Signals und Slots"),
wenn ich sehe,
wie klar und schön allein der "Sprachgebrauch" (die Befehle) von Pascal ist,
wenn ich sehe,
wie schnell es auch einem Anfänger gelingt, mit wenigen Mausklicks mit "Lazarus" eine "Hello World" Ausgabe oder sogar einen kleinen Taschenrechner zur programmieren,
wenn ich sehe,
wie einfach "Cross-Compiling" für Windows und Linux ist (Kompilierung allerdings ausgeführt auf eigenständigen virtuellen Rechnern),
wenn ich sehe,
dass das fertige Programm "aus einem Guss" ohne irgendwelche zusätzliche Programme (virtuelle Maschine im Hintergrund [C#, Java]) auf beiden "großen" Plattformen läuft
wenn ich sehe,
dass es sogar mir gelungen ist, eine Datenbank (SqLite) in ein Lazarus-Programm einzubinden
wenn ich sehe,
wie freundlich die Community hier selbst auf "dumme Fragen" reagiert,
wenn ich sehe,
wie liberal und offen die Lizenzierung von Lazarus-erstellten Programmen ist,
wenn ich sehe,
was Lazarus kostet (nämlich nichts),
wenn ich sehe,
usw. usw.

dann verstehe ist die Diskussion hier ganz einfach nicht: Diese Frage stellt sich aus meiner Sicht schlicht nicht (hoffentlich!)

Aliobaba

P.S.: In diesem Zusammenhang: Danke den Programmierern dieses tollen Projekts und Danke der freundlichen Community hier!!

[Mathias]

dann verstehe ist die Diskussion hier ganz einfach nicht: Diese Frage stellt sich aus meiner Sicht schlicht nicht (hoffentlich!)

Da bin ich gleicher Meinung mit dir.

wie freundlich die Community hier selbst auf "dumme Fragen" reagiert,

Da ist zusätzlich noch ein grosser plus-Punkt. Das C++ und Java- Forum sind das purer Gegenteil. So richtig helfen konnte die bis jetzt nicht, nur dumme Sprüche klopfen.

P.S.: In diesem Zusammenhang: Danke den Programmierern dieses tollen Projekts und Danke der freundlichen Community hier!!

Die Entwickler von fpc/Lazaurs habe sich wirklich ein grosses Lob verdient.

[mschnell]

Das C++ und Java- Forum sind das purer Gegenteil. So richtig helfen konnte die bis jetzt nicht, nur dumme Sprüche klopfen.

Warst Du mal in einem Typo-3 Forum ? Tenor: "Klar können wir helfen, aber nur gegen Bezahlung !".

Ergebnis: das geerbten Typo-3 Projekt weggeworfen und in Wordpress neu entwickelt

-Michael

[Mathias]

Warst Du mal in einem Typo-3 Forum ? Tenor: "Klar können wir helfen, aber nur gegen Bezahlung !".

Ich bin auch in mehreren Foren angemeldet, aber so etwas ist mit nie begegnet.

[mschnell]

aber wenn du der Meinung bist Lazarus und der GDB stehen dem .Net Debugger in nichts nach muss ich an deiner geistigen Gesundheit zweifeln. Um ehrlich zu sein ist mMn Lazarus mit gdb die schlechteste Debugging software die ich seit langem gesehen habe, Delphi Debugger, Java Debugger und auch .Net Debugger, selbst der Atmel Debugger für den AVR Microcontroller mit dem ich aktuell arbeite sind da besser. (Besser in sinne von mehr Funktionen bzw zeigen mehr Informationen).

Für besseres Debuggen Kosten der Performance (bei .Net natürlich Standard), lässt sich teilweise auch bei NativeCode bewirken:
- weniger Optimierung
- Range-Check aktivieren.

Was vermutlich in fpc nicht realisiert ist, aber ein nettes Debug-Feature (das bei .Net natürlich Standard ist) wäre, eine Art Reference Counting für Objekte zu aktivieren, das allerdings nicht ein automatisches free bei Reference-Count = 0 macht, sondern nur eine Exception schmeißt, wenn ein Objekt gefreed wird, auf das noch eine (weitere) Referenz besteht.

-Michael

[Mathias]

Was vermutlich in fpc nicht realisiert ist, aber ein nettes Debug-Feature (das bei .Net natürlich Standard ist) wäre, eine Art Reference Counting für Objekte zu aktivieren, das allerdings nicht ein automatisches free bei Reference-Count = 0 macht, sondern nur eine Exception schmeißt, wenn ein Objekt gefreed wird, auf das noch eine (weitere) Referenz besteht.

Ich denke solche Abfragen brauchen recht viel Ressourcen, und dies würde dann den effizienten Code, welcher fpc erzeugt wieder zu nicht machen.

Nur schon Bereichsprüfungen, so wie -Cr, verbrauchen Leistung.

[Warf]

Was mich vor allem stört beim Lazarus gdb debugging, bei .Net/Visual Studio geht, man kann man den Wert von Variablen beobachten, das geht zwar in Lazarus auch von lokalen Variablen, aber nicht bei globalen Variablen, bei Records und Klassen, bei Zeigern (also das dereferenzieren) bei oder bei arrays. Kurz um wenn man diese Dinge debuggen möchte muss man Umwege gehen und das kostet jede Menge Zeit

[Mathias]

Wen ich ehrlich bin, den Debugger habe ich bis jetzt nicht genutzt. zum überwachen einer Variable, habe ich bis jetzt immer WriteLn oder ShowMessage benutzt.

[Warf]

Wen ich ehrlich bin, den Debugger habe ich bis jetzt nicht genutzt. zum überwachen einer Variable, habe ich bis jetzt immer WriteLn oder ShowMessage benutzt.

Das geht zwar auch, und ist für eine Variable auch kaum Aufwand, aber bei 3+ Variablen ist das doch recht nervtötend, einfach Strg+Alt+L drücken, einen Break point setzen und du kannst an diesen Breakpoint alle lokalen Variablen und deren Werte sehen, sowie mit jedem Step den du im Debugger machst die veränderungen sehen, ist grade für Schleifen zu kontrollieren oder ähnliches deutlich angenehmer. Ich habe mir mitlerweile ein ganzes Debugging Fenster auf einem Zweiten Bildschirm gemacht , damit geht das Debuggen recht angenehm, kommt aber dennoch kommt das nicht an den Visual Studio Debugger ran.
Wenn ich keinen Zweiten Bildschirm zur Verfügung habe, habe ich den Aufrufstack und die Lokalen Variablen dennoch immer offen (Bei Anchor docking einfach als Tab beim Objektinspektor die lokalen variablen bzw. im Projektinspektor den Aufrufstack dazu getan, denn ich brauche eh nie beide Fenster auf einmal).
Früher habe ich auch mit Ausgaben gedebuggt, doch mit den Debugger Features geht es so viel besser, und grade deshalb finde ich es schade dass der GDB für Lazarus so wenig unterstützt.

Ich denke solche Abfragen brauchen recht viel Ressourcen, und dies würde dann den effizienten Code, welcher fpc erzeugt wieder zu nicht machen.

Nur schon Bereichsprüfungen, so wie -Cr, verbrauchen Leistung.

Beim debuggen ist mir die Performance doch egal, da will ich möglichst viele Informationen haben, egal ob das Programm dafür doppelt so lange pro operation braucht

Edit: Ich muss mich korrigieren, Records und Globale Variablen lassen sich doch anzeigen (Globale Variablen mittels überwachte ausdrücke), Bei Records war bisher nur das Problem dass ich das Fenster nie groß genug hatte um das zu sehen, da die Elemente hintereinander aufgelistet sind.
Edit 2: Habe sogar grade per Zufall rausgefunden dass man über die Überwachten Ausdrücke doch sogar Klassen sich anzeigen lassen kann, ist aber ziemlich versteckt, kam grade nur per Zufall drauf. Also von der Funktionalität doch besser als erwartet, allerdings extrem verwirrend strukturiert.

Ich denke ich werde mich mal eingehend mit allen Debugger Features auseinandersetzen und dann eventuell hier ein Tutorial dazu schreiben, da ich glaube viele Anfänger wissen nicht wie man richtig debuggt. (Außerdem bin ich aktuell sehr von den Debuggerfeatures überrascht, ich finde grade viele neue die ich vorher noch nicht kannte/vermisst habe, ich hätte mir das Fenster überwachte ausdrücke Früher mal anschauen sollen

[wp_xyz]

Um mit dem Debugger per "Überprüfen/Ändern" oder "Eigenschaften überwachen" Objekt-Eigenschaften prüfen zu können, muss man den Namen der objekt-internen Variable eingeben, also üblicherweise den mit dem vorangestellten "F". Um z.B. den ItemIndex einer Listbox abzufragen, gibt man "ListBox1.FItemIndex" ein. Natürlich gibt es Ausnahmen: für den Text eines Edit braucht man sinnigerweiser "Edit1.FCaption". Und besonders lästig wird es, wenn an die Items einer TStringlist oder TList will, da greife ich auch zum WriteLn. Und wenn sich hinter dem Getter einer Eigenschaft eine Funktion versteckt, muss man natürlich passen, da der Debugger keinen Code ausführen kann - aber das kann selbst Delphi nicht. Aber generell komme ich mit dieser "F"-Methode sehr weit und kann die meisten Fälle abdecken.

[Michl]

Für mich wichtig ist auch die Tastenkombination <Strg> + <F5>. Geht man beim Debuggen im Quelltext auf einen Bezeichner und drückt diese, wird der Bezeichner in die Liste der überwachten Ausdrücke hinzugefügt (somit spart man sich die Tipparbeit).
Hat man den Togglebutton mit dem kleinen Debugsymbol in oberen Toolbar des Fensters "Liste der überwachten Ausdrücke" eingeschaltet, hat man sämtliche objekt-internen Variablen aufgelistet.

[mschnell]

Ich denke solche Abfragen brauchen recht viel Ressourcen, und dies würde dann den effizienten Code, welcher fpc erzeugt wieder zu nicht machen.

Natürlich !!! Sollte man - wie Bereichsprüfung - auch nur beim Debuggen aktivieren.
-Michael