Ist die Programmierung mit Lazarus Free-Pascal zeitgemäß??

[Warf]

Den Du auf einem AVR an welcher Stelle brauchst? Gib mal ein Beispiel. Ich komme wie gesagt vom Assembler, vielleicht denke ich da zu low-level.

Wenn etwas nen setup braucht. Z.B. bei nem USART serial, ein teil aus meiner serial klasse (sorry für die formatierung, ist ein define damit ich mehrere serial ports mit verschiedenen typen verwenden kann):

Code: Alles auswählen

  Serial##n##Stream() {\
    static bool initialized = false;\
    if (initialized) return;\
    \
    initialized = true;\
    \
    UBRRH(n) = UBRRH_VALUE;\
    UBRRL(n) = UBRRL_VALUE;\
DO_2X(n);\
    UCSRB(n) |= (1 << TXEN(0)) | (1 << RXEN(0));\
    UCSRC(n) = (1 << UCSZ(n,1)) | (1 << UCSZ(n,0));\
  }\
 

So muss ich nicht mehr dran denken den initializer aufzurufen, sobald ich die klasse einmal verwendet habe ists initialisiert. Die benutzung ist dann

Code: Alles auswählen

io::Searial0Stream ss;
ss << PSTR("Hallo Welt!") << io::endl;

[Timm Thaler]

Auch auf dem AVR Arbeite ich mit Klassen, zwar nicht in dem Umfang wie bei Lazarus aber ich tue es.

Habe ich versucht, erzeugt nur unnötig Overhead.

Aber was ist z.b. wenn du eine Variable Definierst? Am ende der Funktion wird diese Variable in Pascal nicht frei geben.

Häh? Doch. Natürlich. Wäre ja schlimm wenn nicht.

Ein Blick ins erzeugte Assembler-Listing ist da sehr hilfreich. Variablen die in Funktionen / Prozeduren deklariert werden, sind nicht im Ram, sondern in den Registern angelegt. Oder falls diese nicht reichen auf dem Stack (also auch wieder Ram, aber nicht an fester Adresse). Und wenn die Funktion verlassen wird, stehen diese Register oder der Platz auf dem Stack wieder zur Verfügung.

Globale Variablen dagegen werden fest im Ram angelegt. Es kann durchaus sinnvoll sein, eine lokale Variable in einer Funktion, die häufig verwendet wird, als globale Variable anzulegen, weil dann der Zugriff deutlich schneller sein kann (lds-sts statt Stackpointer+Offset+ld-st).

Klassen-Variablen dagegen werden soweit ich das sehe auf dem Heap abgelegt, und ja, da wirds dann lustig mit der Verwaltung. Ich hab es mir ganz schnell abgewöhnt auf dem AVR mit Klassen zu arbeiten, auch wenn das nett ist, aber wie gesagt es erzeugt massiv Overhead bei jedem Funktions-/Prozeduraufruf. Und ehrlich, selbst bei meiner doch sehr aufwendigen Heizungssteuerung kann ich gut ohne Klassen leben, und bei kleineren Projekten erst recht. Ich sehe hier keine Vorteile, die die Nachteile aufwiegen würden.

[pluto]

Habe ich versucht, erzeugt nur unnötig Overhead.

Mag sein, im Moment verwende ich noch Arduino C Klassen z.b. für LCD'S und Sensoren und co.

Häh? Doch. Natürlich. Wäre ja schlimm wenn nicht.

Was passiert, wenn du ein Dynamischen Array erstellst? Wird diese Frei gibst?

Ein Blick ins erzeugte Assembler-Listing ist da sehr hilfreich.

Das habe ich schon mal irgendwo gehört... und dann haben wir einfach nur ein break in der case Anweisung "vergessen" in "Arduino C"

Globale Variablen dagegen werden fest im Ram angelegt. Es kann durchaus sinnvoll sein, eine lokale Variable in einer Funktion, die häufig verwendet wird, als globale Variable anzulegen, weil dann der Zugriff deutlich schneller sein kann (lds-sts statt Stackpointer+Offset+ld-st).

Guter Hinweis. Es gibt Leute die "erstellen" eine Variable für eine forschleife in C z.b. vor der Forschleife.

Ich hab es mir ganz schnell abgewöhnt auf dem AVR mit Klassen zu arbeiten, auch wenn das nett ist, aber wie gesagt es erzeugt massiv Overhead bei jedem Funktions-/Prozeduraufruf.

Ah, da geht mein ganzer RAM hin... habe mich schon gewundert... Es heißt ja auch: Arduino C und nicht Arduino C++

Und ehrlich, selbst bei meiner doch sehr aufwendigen Heizungssteuerung kann ich gut ohne Klassen leben, und bei kleineren Projekten erst recht. Ich sehe hier keine Vorteile, die die Nachteile aufwiegen würden.

Auf einem STM32 kann man gut mit Klassenarbeiten bzw. ähnliche Konzepte. Aber ein STM32 hat ja auch deutlich mehr Leistung als wohl jeder AVR... Cool sind natürlich auch die ESP32, wobei mit dem habe ich noch nie was gemacht.
Im KTT haben sie mit einem EP32 eine Türöffnung gebaut, jedoch ohne W-Lan oder Bluetooth, sondern mit ganz normalen Lan kabel und POE(Selbst gebaute Platine).

Es gibt schon viele Möglichkeiten. Genau wie mit den "IDE'S" oder den Programmiersprachen. Die Arduino IDE, würde ich z.b. nicht als IDE bezeichnen, die kann sich einiges von Lazarus abschauen. Die Arduino IDE ist noch "älter" würde ich sagen. Sie öffnet sage und schreibe um die 16000 Java Dateien(bei mir aufjedenfall) kann man schön mit "lsof|grep -i inotify" sehen.
Finde ich persönlich etwas übertrieben... aber gut.

[Timm Thaler]

Was passiert, wenn du ein Dynamischen Array erstellst?

Ich hab gerade mal geschaut, selbst in meinen nRF Routinen übergebe ich Arrays nur by reference. Ich hatte noch nicht die Verlegenheit, auf dem AVR dynamische Arrays zu benötigen.

Buffer haben eine feste Länge, Displaybuffer, Payload, da weiß ich wie groß die sind und die werden global angelegt. Ringbuffer für Rx, Tx haben auch eine feste Größe.

Ja, kann sein, dass man dynamische Arrays selbst freigeben muss, ich hatte den Fall noch nicht, und mir wäre unwohl, auf dem AVR mit begrenztem Ram mit Array unbekannter oder wechselnder Größe zu arbeiten.

Guter Hinweis. Es gibt Leute die "erstellen" eine Variable für eine forschleife in C z.b. vor der Forschleife.

Oh, wenn Du DIESE Tür wirklich aufmachen willst:

Prinzipiell arbeitet For erstmal mit 16 Bit, auch wenn a nur von 1 bis 4 zählt. Mit Optimierung auf -O3 nimmt For dann 8 Bit. Idealerweise braucht es dafür ein Register. Und das geht dann auch flott. Wenn a lokal in der Prozedur deklariert ist.

Für eine For-Schleife im Hauptprogramm ist a aber global deklariert. Liegt also im Ram. Das heisst, hier wird wirklich bei jedem Schleifendurchlauf a aus dem Ram ins Register geladen, inkrementiert, verglichen und in den Ram zurückgeschrieben. => For-Schleifen im Hauptprogramm sind eine doofe Idee.

Nun kann es natürlich sein, dass in der Funktion so viele Variablen parallel verarbeitet werden, dass die Register nicht reichen. Dann kann es passieren, dass a auf dem Stack liegt: a ins Register holen, inc, vergleichen, auf den Stack schreiben. Inklusive Verwaltung der Stack-Adressierung. Das ist dann noch langsamer als im Hauptprogramm. => Funktionen möglichst kurz halten.

Wobei das nur bei Programmen relevant wird, wo es auf Geschwindigkeit ankommt, Software-PWM, Echtzeit-Datenerfassung z.B. Bei den meisten Anwendungen wirst Du kaum merken, ob die For-Schleife mit 16 oder mit 8 Bit zählt. Das hat aber einen netten Nebeneffekt: Timing mit einer For-Schleife kannst Du vergessen - eine andere Optimierung eingestellt und nix stimmt mehr.

[Dee]

Bitte nicht vom Thema abschweifen! Lagert das bitte in einen anderen Thread aus. Danke.

Ich finde die Themen-Diskussion bis jetzt, wenn es denn beim Thema des Themen-Erstellers bleiben würde, sehr interessant.

Wäre schön gewesen, wenn der Themen-Ersteller eventuell ein paar Anhaltspunkte gegeben hätte, wie man soetwas feststellen könnte (zeitgemäße Programmiersprache) oder über was in anderen Foren diskutiert wurde, da nicht jeder sich mit dieser Materie auskennt oder nicht jeden Foren-Eintrag dazu gelesen hat. Nicht negativ gemeint, nur konstruktive Kritik.

Ich weiß gar nicht, was eine Sprache ausmacht, die zeitgemäß ist. Gibt es soetwas überhaupt? Eine zeitgemäße Programmiersprache? Vielleicht kann mich ja jemand aufklären.

Assembler würde ich persönlich nicht nutzen, um eine GUI-Anwendung zu erstellen, da es Entwicklungsumgebungen gibt (z.B. RAD), die das vereinfachen, die dann aber bestimmte Sprachen nutzen, welche weit verbreitet sind. Ich will damit nicht sagen, dass Assembler schlecht ist, nur für bestimmte Projekte eben nicht zeitgemäß, da weiterentwickelte Programmiersprachen vorhanden sind, welche bestimmte Umsetzungen für Projekte durch Codegenerierung vereinfachen oder durch vorhandene Bibliotheken oder Frameworks und was nicht alles. Ich denke, wenn man mehr Aufwand für etwas betreiben muss, obwohl es bessere Lösungen oder Alternativen gibt, die weniger Ressourcen benötigen und/oder schneller sind, sind sie nicht mehr zeitgemäß. Das wäre so meine Definition. Aber das deckt sich ja mit der aus dem Duden - sinngemäß zumindest.

Edit: Mir ist noch etwas eingefallen: Wenn ich mich entscheiden müsste, ob das Programmieren mit Lazaurs zeitgemäß ist, würde ich eher - nach langem Zögern - für ein Nein entscheiden, weil:

[*] Ich kann unter Lazarus nicht auf alle Steuer-Elemente und Objekte des Betriebssystems zugreifen, da diese nicht zur Auswahl in der Komponenten-Palette stehen (ob man die jetzt selber schreiben kann, weiß ich nicht) [nur auf Windows bezogen, wie sieht es bei iOS aus?]
[*] Metro-Anwendungen (Kachel-Design) müsste man sich mühsam selber zusammenklicken (unter neuen Delphi-Versionen leichter erstellbar, glaube ich)
[*] Smartphone-Apps zu entwickeln, ist möglich, aber noch lange nicht ausgereift genug (Kann man iOS-Anwendungen erstellen? Laufen diese auf allen Modellen? Welche Komponenten stehen zur Verfügung? Ist es leicht zu zumzusetzen? Wie sieht es mit Tutorials oder Referenzen aus?)
[*] Webanwendungen erstellbar? (selber noch keine erstellt und kurze Recherche ergab keine Treffer)

Lazarus ist eher für Desktop-Anwendungen ausgelegt, aber wie sieht es mit anderen Plattformen aus? Ich denke, dass da Lazarus noch extrem hinterher hinkt.

-- Dee

[MacWomble]

Ich würde 'zeitgemäß' in Bezug auf eine Programmiersprache (mit weniger Worten) so definieren:

Läuft unter den möglichst allen Betriebssystemen und unterstützt ein breites Spektrum alter und aktuell erhältlicher Hardware,
aktuell geforderte Problemlösungen sollten damit umgesetzt werden können und die Syntax sollte auf einem guten, verständlichem Niveau sein.

Anmerkungen:
Metroanwendungen sind m.E nicht zeitgemäß sondern absolut unbrauchbar,
FPC ist keine Sprache für Webanwendungen.
Zugriff auf Steuerelemente des BS muss durch das BS bereitgestellt werden.
Smartphone-SW funktioniert, aber auch heirfür ist die Spreche nicht gemacht.

Haben diese Punkte wirklich mit 'zeitgemäß' zu tun?

[Niesi]

Ich würde 'zeitgemäß' in Bezug auf eine Programmiersprache (mit weniger Worten) so definieren:

Läuft unter den möglichst allen Betriebssystemen und unterstützt ein breites Spektrum alter und aktuell erhältlicher Hardware,
aktuell geforderte Problemlösungen sollten damit umgesetzt werden können und die Syntax sollte auf einem guten, verständlichem Niveau sein.

Anmerkungen:
Metroanwendungen sind m.E nicht zeitgemäß sondern absolut unbrauchbar,
FPC ist keine Sprache für Webanwendungen.
Zugriff auf Steuerelemente des BS muss durch das BS bereitgestellt werden.
Smartphone-SW funktioniert, aber auch heirfür ist die Spreche nicht gemacht.

Haben diese Punkte wirklich mit 'zeitgemäß' zu tun?

Warum sollte FP "keine Sprache" für Webanwendungen oder Smartphonesoftware sein?
An der Sprache selbst scheitert das ganz sicher nicht - meines Wissens ist unter Delphi beides möglich, dann kostet es (in der kostenlosen Version ist das nicht mit drin, meine ich - bin aber nicht sicher).

Lazarus bietet zum Beispiel mit fpWeb und pas2js sehr wohl Möglichkeiten, www-Anwendungen zu entwickeln - die Frage ist, ob das reicht. Das kann ich leider nicht beurteilen, da ich mich zumindest zurzeit ausschließlich Software zur Berechnung von Verzahnungen entwickle.

Mich interessiert bei meiner Frage, ob Lazarus und Free-Pascal "zeitgemäß" sind, in erster Linie: gibt es etwas besseres?

Und da behaupte ich: Nein.

Es gibt anderes, aber nichts besseres. Und nur um etwas anders zu machen ist mir mein Projekt zu wichtig, meine Zeit zu schade und ich bin nicht modeaffin genug. Mein ehrlicher Einduck: die Leute, die behaupten, anderes sei ja so viel besser und dann keine Belege liefern können, sind auf der Suche nach Entschuldigungen dafür, dass sie nichts fertig bekommen. Und die Leute, die immer einen Riesenhype um unfertige Neuheiten machen, tun dies aus rein kommerziellen Gründen.

[MacWomble]

Warum sollte FP "keine Sprache" für Webanwendungen oder Smartphonesoftware sein?
An der Sprache selbst scheitert das ganz sicher nicht - meines Wissens ist unter Delphi beides möglich, dann kostet es (in der kostenlosen Version ist das nicht mit drin, meine ich - bin aber nicht sicher).

Natürlich kann man mit FP Webanwendungen entwerfen und dann in Java konvertieren, aber das ist nicht der Sinn der Sprache.
Webanwendungen sind idealerweise in php geschrieben, und das wird von FP nicht unterstützt.

[MacWomble]

Es gibt anderes, aber nichts besseres.

Genau so sehe ich das auch.

[Ich934]

Ich glaube das kommt auch immer auf die Anwendung an. Es gibt auch sehr bekannte Anwendungen, welche mit Delphi/Pascal entwickelt werden (z. B. HeidiSQL). Es ist also nicht unbedingt ein Nischenprodukt.

Auf der anderen Seite werde auch ich schief angeschaut, wenn ich sage, ich entwickle primär in Cobol und RPG. Das ist aber das, was halt bei uns auf einer iSeries vorherrscht. Da könnte ich auf mit Java und C++ arbeiten. Effektiver sind aber halt diese alten Sprachen.

C# kann ich auch plattformunabhängig programmieren. Der neue .net Core soll ja dann auch nativ laufen. Aber ich brauche da ein Framework. Das habe ich hier nicht.

Auf der anderen Seite, wenn ich das Prinzip kann, dann ist die Sprache kein Problem. Da muss ich mir doch dann nur kurz in Syntax und Besonderheiten einlesen...

Ich entwickle wieder gern mit FP und Lazarus. Auch wenn das vielleicht wieder eine Niesche ist...

[Timm Thaler]

FPC ist keine Sprache für Webanwendungen.

Kommt drauf an, was für Dich "Webanwendungen" sind?

Solls im Browser laufen? Dann geht eh nur JS oder Java. Soll es Daten fürs Web bereitstellen? Dann geht Pascal.

Meine CGIs in Pascal arbeiten vorzüglich und ressourcenschonend. Fast-CGI geht auch. Ja ok, das sind nur kleine Programme, die im Intranet Daten und Diagramme aufbereitet zur Verfügung stellen. Mich hat halt abgeschreckt, das in Python oder PHP zu machen, wo dann jedesmal erstmal der Interpreter aufgerufen wird, wenn die Daten angefordert werden.

[six1]

...ich finde den Verlauf und auch die Themen, welche hier mit eingebracht wurden, interessant.

Als ich mich vor über 30 Jahren von einer Interpreter Sprache trennen wollte, weil das viel zu unflexibel und langsam war, habe ich mich damals lange damit beschäftigt, was es werden soll.
Motorola uC habe ich damals in C programmiert. C war aber für WIN Anwendungen eine Katastrophe. Ich wollte in erster Linie ein Werkzeug, um Anwendungen zu entwickeln und mich nicht damit beschäftigen, wie die Welt entstand...
Da kam damals Delphi 2 32 Bit im Bundle mit Delphi 1 16 Bit als RAD Tool genau richtig. In die Sprache kann man sich schnell einarbeiten, wie es bereits erwähnt wurde.
Warum aus Delphi Lazarus und FPC wurde, hatte ich bereits geschrieben.

Genau so verhält es sich bei mir mittlerweile beim Programmieren von Atmels... ich bin dabei völlig pragmatisch und an keinen "Glauben" gebunden.
Wenn ein "Werkzeug" gut und schnell funktioniert, benutze ich es.
Hier setze ich mittlerweile auf Bascom für meine Atmega Projekte. Das würde ich mal als Basic RAD System für Atmel bezeichnen.
Ich habe sogar mal eine HAL in Bascom für Atmegas geschrieben... geht nicht gibt es nicht; in keiner Sprache
Die Frage ist immer: Wie hoch ist der Aufwand.

Wenn ich hier also lese, dass DIES oder DAS nicht gut geht oder ist in Pascal, wäre im betreffenden Fall evtl. ein Wechsel zu einer anderen Sprache angepasst.
Verbesserungspotential gibt es immer, aber mit den Jahren gewöhnt man sich auch an die ein oder andere Macke und kennt die Stellen, wo ein fail vorprogrammiert ist

Die Diskussionsgrundlage ist ein derart breites Feld und jeder kommt mit unterschiedlicher Bildung, Erwartung und Zielen, dass die Antwort ob Pascal/Lazarus zeitgemäß ist, wohl eine sehr individuelle Sicht der Dinge bleiben wird. ( im Unterschied zum Atmen )

[pluto]

Bitte nicht vom Thema abschweifen! Lagert das bitte in einen anderen Thread aus. Danke.

Ich finde, dass passt schon irgendwie alles zusammen. Es geht darum, warum man "alte" "Sachen" nutzt und keine Modernern.
Bei AVR geht es um die Programmierung. Das geht inzwischen auch mit Pascal.
Es geht, um Meinungen.

Wäre schön gewesen, wenn der Themen-Ersteller eventuell ein paar Anhaltspunkte gegeben hätte, wie man soetwas feststellen könnte (zeitgemäße Programmiersprache) oder über was in anderen Foren diskutiert wurde, da nicht jeder sich mit dieser Materie auskennt oder nicht jeden Foren-Eintrag dazu gelesen hat. Nicht negativ gemeint, nur konstruktive Kritik.

Es ging Allgemeine Punkte, die sind für jeden anders, wie du ja bereits hier siehst.

Ich weiß gar nicht, was eine Sprache ausmacht, die zeitgemäß ist. Gibt es soetwas überhaupt? Eine zeitgemäße Programmiersprache? Vielleicht kann mich ja jemand aufklären.

Siehe die Meinungen von "MacWomble 19/5/2019, 10:41" und von "Warf".

Assembler würde ich persönlich nicht nutzen, um eine GUI-Anwendung zu erstellen, da es Entwicklungsumgebungen gibt (z.B. RAD), die das vereinfache

Es gibt aber Leute, die das machen.

Ich will damit nicht sagen, dass Assembler schlecht ist, nur für bestimmte Projekte eben nicht zeitgemäß

Eher nicht geeignet.

[*] Ich kann unter Lazarus nicht auf alle Steuer-Elemente und Objekte des Betriebssystems zugreifen, da diese nicht zur Auswahl in der Komponenten-Palette stehen (ob man die jetzt selber schreiben kann, weiß ich nicht) [nur auf Windows bezogen, wie sieht es bei iOS aus?]

Du kannst im Prinzip auf alles zugreifen, mit den entsprechenden Rechten. Gerade unter Linux ist das recht einfach.

[*] Metro-Anwendungen (Kachel-Design) müsste man sich mühsam selber zusammenklicken (unter neuen Delphi-Versionen leichter erstellbar, glaube ich)

Zum Beispiel. Meine Oberfläche mit den Standard Komponenten, sieht im Prinzip aus, wie eine Windows 95 Anwendung.

[*] Webanwendungen erstellbar? (selber noch keine erstellt und kurze Recherche ergab keine Treffer)

Dann hast du mit den Falschen begriffen gesucht. Ich habe schon einige WebAnwendungen in Form von WebServern und WebSocketServern erstellt.

Lazarus ist eher für Desktop-Anwendungen ausgelegt, aber wie sieht es mit anderen Plattformen aus? Ich denke, dass da Lazarus noch extrem hinterher hinkt.

Ich kann damit relativ leicht Anwendungen für AVR schreiben oder auch für "fast" jede andere Anwendungen.

ich bin dabei völlig pragmatisch und an keinen "Glauben" gebunden.
Wenn ein "Werkzeug" gut und schnell funktioniert, benutze ich es.

Genau. Es sind bloß Werkzeuge.

[Timm Thaler]

Hier setze ich mittlerweile auf Bascom für meine Atmega Projekte. Das würde ich mal als Basic RAD System für Atmel bezeichnen.

Das RAD für Atmel ist das Atmel Studio, mit Assembler und C. Von Bascom hab ich ganz schnell die Finger gelassen, abgesehen davon, dass es damals teilweise grauenhaften Code produzierte, manövriert man sich damit wieder in so eine Sackgasse, wo man von einem Anbieter einer proprietären Software abhängig ist. Und wenn der mal nicht mehr will...

Wenn ich hier also lese, dass DIES oder DAS nicht gut geht oder ist in Pascal, wäre im betreffenden Fall evtl. ein Wechsel zu einer anderen Sprache angepasst.

Im Gegenteil, mit Pascal geht vieles, was mit anderen Sprachen nicht geht - C mal ausgenommen.

Ich kann meine nRF24 Bibliothek für den AVR und das Gegenstück für den ARM-Raspi nahezu parallel in Pascal führen. Theoretisch könnte ich sie komplett als eine Bibliothek führen, wenn ich komplett mit Klassen arbeiten würde - was ich auf dem AVR nicht will. Mach das mal in Bascom, oder PureBasic, oder Python.

Ich kann auf dem PC unter Windows für Linux, und für ARM Linux, und für AVR embedded programmieren, mit einer IDE. Ich kann ein Programm - mit Abstrichen an das Aussehen der GUI, GTK ist halt einfach häßlich - unter Windows erstellen, und dann ohne große Änderungen für den Raspi kompilieren - und das läuft.

[six1]

Ich kann meine nRF24 Bibliothek für den AVR und das Gegenstück für den ARM-Raspi nahezu parallel in Pascal führen. Theoretisch könnte ich sie komplett als eine Bibliothek führen, wenn ich komplett mit Klassen arbeiten würde - was ich auf dem AVR nicht will. Mach das mal in Bascom, oder PureBasic, oder Python.

Timm, das will ich gar nicht.
Ich habe Bascom und entwickle auf Atmega Typen in meinen Geräten Software, welche ich entwickelt habe und verkaufe. Die Software steht und bedarf keiner wesentlichen Änderungen.
Um zu diesem Ziel zu kommen, habe ich wenig investieren müssen und stabile Programme.

Wie ich schrieb: Ich sehe das pragmatisch.

Ich kenne den Entwickler von Bascom und wenn er sich mal zur Ruhe setzen sollte, dann ist die Zeit wohl reif, mich auch zur Ruhe zu setzen
...ne im Ernst: Dann nehme ich eben das Nächste Tool, was mir zusagt und meine Wünsche erfüllt... what shall's