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

[Warf]

Aus der C / C++ Ecke kommt dann sofort: Nimm halt C(++), das kann alles. Stimmt leider.

Ich hab mir mal nen Pic microcontroller geholt, der kann nicht mal C++. Da muss man sich mit reinem C rumschlagen, das ist noch schlimmer.

Aber grundsätzlich ist es eher eine frage des Projekts. Für einen Microcontroller würde ich tatsächlich C++ nehmen, denn jede Designentscheidung in C++ ist gemacht um Performance zu maximieren und resourcen benutzung zu minimieren. Grade auf einem AVR der echt wenig hat (16 mhz ist ja recht wenig) kann das schon einen unterschied machen.
Wenn ich ne Desktopanwendung mache die daten visualisieren soll, bei denen performance wichtig ist (i.e. große menge daten) und ein schnelles und schönes UI wichtig ist nehm ich lazarus, und wenn ich ne anwendung für meinen server schreib die einfach schnell geschrieben sein soll und einfach funktionieren soll, dann nehm ich Java.

Jede sprache ist nur gut relativ zu einem projekt

[pluto]

Mein Eindruck ist der, dass man bei Lazarus/FreePascal wesentlich schneller zu einem Erfolgserlebnis gelangt als bei vielen anderen Programmiersprachen.

Es kommt immer darauf an, was man gerade macht. Ich habe mich vorhin mit der StringGird befasst. Ich wollte eigentlich nur eine einfache Normale Sortierung pro Spalte einführen die man per Doppel Klick umstellen kann. Habe ich auch geschafft, auf den ersten Blick auf dem zweiten Blick: Die Sortierung ist nicht Natürlich.
Es gibt viele stellen bei den Komponenten, die die Entwicklung von einfachen Oberflächen bereits stören, finde ich.
Ich schreibe daher lieber Anwendungen ohne Grafische LCL Oberfläche. Jetzt mache ich, dass für verschiedene Projekte. Jedes mal kommt der Gedanke: Du müsstest mal eine eigene GUI erstellen.
Warum haben viele Komponenten ein Color Eigenschaft? Keiner der Standard Buttons unterstützt sie.

Bei vielen Komponenten finde ich einfach Probleme. Z.B. die Buttons sehen aus, wie von Windows 95... da habe ich letzten im Verein ein Programm gesehen, was nur unter Windows 95 Läuft und ein IR-Spektrometer steuert. Wir haben zwar vor das Protokoll zu "decodieren", aber das dauert natürlich seine Zeit.

Auch jetzt die Oberfläche, die ich mir gebaut habe, die sieht irgendwie nicht einladend aus.

Ich weiß natürlich warum das so ist: Das sind Kompromisse die man einfach eingehen muss, wenn man Lazarus Verwendet. Das hat nichts mit Gejammer zu tun. Ich könnte ja auch einfach, eine andere Umgebung nutzen, die diese Nachteile nicht hat. Mache ich aber nicht.

So ähnlich ist es auch mit einer Sprache. Ich schließe mich aber Warf's aussagen an. In Pascal gibt es einige Dinge, die einfach Störend sind, z.b. der Zikuläre Unit Aufruf, den ich immer wieder erwähne. Scheinbar kann man das nicht ändern, aber andere dinge können sie ändern.
Ich habe mal gehört, dass gerade weil viele Dinge in Pascal fehlen, die "Entwickler", lieber zu Java oder anderen Sprachen wechseln. Sie haben es erst in Object Pascal versucht und dann festgestellt: Das geht nicht und das geht auch nicht oder nur sehr schwer.

Ein Beispiel:
Senden und Empfangen, ist schon ein komplexes Thema in Pascal, in Rust gibt es dafür eine Lösung. Das Problem dabei ist:
Du möchtest "gleichzeitig" Senden können und Empfangen können und dabei keine Sendung verlieren. Ich glaube, es spielt keine große rolle, ob du Daten über ein Uart oder über TCP einlist.

Ich hab mir mal nen Pic microcontroller geholt, der kann nicht mal C++. Da muss man sich mit reinem C rumschlagen, das ist noch schlimmer.

Ich habe gehört, die sind nicht einfach zu Programmieren, stimmt das?

[Warf]

Ich habe gehört, die sind nicht einfach zu Programmieren, stimmt das?

Weiß ich nicht so wirklich, ich hab nicht so viel damit gemacht, aber man muss einfach sagen Arduino hat für AVR für eine große und lebendige Community gesorgt, was das finden von informationen dazu viel einfacher macht. Beim PIC muss man für viel mehr infos ins datenblatt schauen, was man bei Arduino mit schnellem googlen rausfinden kann.

In dem sinne, ja. Ob es produktiv wirklich viel aufwendiger ist wenn man erst mal drin ist kann ich nicht sagen. Ich hab mir nur damals nen Debugger bei microchip bestellt, und weil ich eh die 15€ Lieferkosten bezahlen musste, dachte ich mir bestell ich mir noch son test board dazu (muss sich ja auch lohnen die bestellung). Aktiv arbeite ich aber vor allem mit meinen arduinos, auch wenn von der reinen verarbeitungsqualität das Microchip board viel besser ist.

[MmVisual]

Ich würde nicht sagen dass Lazarus "Zeitgemäß" ist, vieleher ist Lazarus "Zeitlos".

Wenn jemand atmet frägt man schließlich auch nicht ob es noch "Zeitgemäß" ist zu atmen, solche Dinge sind einfach "Zeitlos"

[siro]

Hallo , ich möchte auch gern noch meinen Senf dazu geben:

Für mich gibt es auch ein klares "JA" zu Pascal/Lazarus

Ich finde Pascal nach wie vor einfach hervorragend, ob "modern" keine Ahnung,
was heisst modern ?, ich kann damit eigentlich alles machen was ich möchte.
Der Code (Syntax) ist sehr übersichtlich und verständlich.
Man liest ihn wie ein Buch ohne grossartig überlegen zu müssen.
Okay man kann auch in Pascal schlechten Code schreiben...

Da ich nun auch schon 2 stellige Jahre in "C" programmiere, habe ich eine sehr gute Vergleichsmöglichkeit.
Ich habe mich in beide Sprachen sehr intensiv eingearbeitet und muss immer wieder feststellen,
das "C" eine echte Katastrophe ist. Wie das mit C++ aussieht kann ich nicht beurteilen,
das war mir bisher erspart geblieben

Thema Pointer und NIL
Ich liebe es und benutze NIL/NULL in Pascal genauso gerne wie in "C"
Was kann man daran nicht mögen ? Eindeutiger geht es doch nicht.

Mit dem Heaptrace in Lazarus finde ich eine sehr gelungene Lösung
und ja, ich habe auch schon vergessen Speicher freizugeben.

OOP:
Ich bin mit Turbo Pascal 7 das erste mit OOP in Berührung gekommen und auch Bücher besorgt.
Ehrlich gesagt habe ich nicht annähernd verstanden wozu das gut sein soll, das geht doch genauso auch ohne.
Hat eine Weile gedauert bis sich mir der Sinn offenbarte.
Die wirklichen Vorteile von OOP hab ich dann erst mit Delphi-3 und den Komponenten erfahren.

Der Syntax von Pascal wurde ja inzwischen auch erweitert. Ob das nötig ist, sei mal dahingestellt:
x+=1; // geht jetzt auch
x++; // dies aber schon nicht mehr....

okay dafür gibt es "inc" und dec, was "C" wiederum nicht kennt.
Wenn schon C spezifischer Syntax mit aufgenommen wird, hätte man es etwas konsequenter machen können,
aber vieleicht geht das ja auch irgendwie. Ich möchte da jetzt nichts negatives hinterlassen, zumal ich es eh nicht benutze.

Ich habe knapp 40 Jahre Pascal hinter mir und ich hoffe, ich nehme es auch noch mit ins Grab,
wobei ich früher noch VIEL Geld für die Compiler ausgegeben muste und nun ist alles kostenfrei
Dazu ein Forum wo man auch mal Fragen kann und hier auch wirklich gute Informationen bekommt,
was will man mehr.

Ja, Pascal ist immer noch Modern und Aktuell.

@Pluto:
Thema PIC:
Ich habe mich mit diesen Teilen schon Jahrzehnte beschäftig.
Die ersten hatten noch ein EEPROM Fenster und nach jeder Softwareänderung hiess es 20 Minuten löschen unter UV-Licht.
Inzwischen haben die ja alle Flash Speicher.
Ob die kompliziert sind würde ich mit "JA" bezeichnen.
Die haben wirklich viele Merkwürdigkeiten.
99 Prozent der Fehler basierten auf BANKSELECT / PAGESELECT Problemen.
Die Speicherverwaltung ist mehr als merkwürdig, zumindest bei den 8 Bittern.
Ich benutze sie aber immer noch sehr gerne, grade die 8 Beinigen für kleine Steuerungen im Modellbaubereich.
Der PIC12F1840 ist zur Zeit mein Favorit.
Progge ich momentn entweder direkt in Assembler oder aber in "C"
Wär schon wenn man die in Pascal proggen könnte. Es gibt dafür aber sogar Pascal Compiler (zu kaufen )

Siro

[pluto]

In dem sinne, ja. Ob es produktiv wirklich viel aufwendiger ist wenn man erst mal drin ist kann ich nicht sagen. Ich hab mir nur damals nen Debugger bei microchip bestellt, und weil ich eh die 15€ Lieferkosten bezahlen musste, dachte ich mir bestell ich mir noch son test board dazu (muss sich ja auch lohnen die bestellung). Aktiv arbeite ich aber vor allem mit meinen arduinos, auch wenn von der reinen verarbeitungsqualität das Microchip board viel besser ist.

Passt ja fast zum Thema.... ich möchte mich eigentlich eher in die STM32F103 Einarbeiten....
Ich Arbeite immer ohne "Debugger"... In der Regel finde ich die meisten Fehler, mit den "einfacheren" Methoden.

Ein Arduino Uno kostet etwa genau so viel wie ein STM32F303 Discovery Board. Dabei hat der STM32F303 deutlich mehr Leistung und Möglichkeiten, aber ist eben auch komplexer.
So ähnlich ist es auch bei Rust und Object Pascal, wobei beides natürlich "Kostenlos" ist. Rust hat deutlich mehr Möglichkeiten, aber für Pascal findet man einfach mehr Infos im Netzt.

Ich würde nicht sagen dass Lazarus "Zeitgemäß" ist, vieleher ist Lazarus "Zeitlos".

Das trifft es. Zeitlos. Die Standard Komponenten, die es gibt, habe ich schon 2007 genutzt.

Wenn jemand atmet frägt man schließlich auch nicht ob es noch "Zeitgemäß" ist zu atmen, solche Dinge sind einfach "Zeitlos"

Nicht unbedingt. Ich meine der atTiny85 dürfte deutlich jünger sein, als ein atMega328.

Ich finde Pascal nach wie vor einfach hervorragend, ob "modern" keine Ahnung,
was heisst modern ?, ich kann damit eigentlich alles machen was ich möchte.

Ich glaube ob mein eine Sprache Großartig ist oder ob man mit einer Sprache alles machen kann was man möchte, darum geht es im Prinzip nicht.
Mit ASM kann ich auch alles machen(wenn ich es könnte), aber wer würde damit größere Projekte umsetzten?

x+=1; // geht jetzt auch
x++; // dies aber schon nicht mehr....

In C gibt es sowas: ++x und x++ das erstere soll besser sein.

Die ersten hatten noch ein EEPROM Fenster und nach jeder Softwareänderung hiess es 20 Minuten löschen unter UV-Licht.

Lustig...

[MacWomble]

Ich würde nicht sagen dass Lazarus "Zeitgemäß" ist, vieleher ist Lazarus "Zeitlos".

Wenn jemand atmet frägt man schließlich auch nicht ob es noch "Zeitgemäß" ist zu atmen, solche Dinge sind einfach "Zeitlos"

Gut gebrüllt, Löwe !

[Timm Thaler]

Ein Arduino Uno kostet etwa genau so viel wie ein STM32F303 Discovery Board. Dabei hat der STM32F303 deutlich mehr Leistung und Möglichkeiten, aber ist eben auch komplexer.

Und meiner Meinung nach immer noch ein Grund für die "ollen" AVR Atmegas: Die bekommt man recht schnell zum Laufen, und dabei kann man viel weniger Fehler machen als wenn man bei einem STM32 erstmal sämtlichen Kram konfigurieren muss.

In C gibt es sowas: ++x und x++ das erstere soll besser sein.

Das sind zwei verschiedene Sachen: ++x inkrementiert erst und dann wird der Wert verarbeitet, x++ verarbeitet erst den Wert und inkrementiert dann. Kann bei Schleifen oder Vergleichen über geht und geht nicht entscheiden.

Für einen Microcontroller würde ich tatsächlich C++ nehmen, denn jede Designentscheidung in C++ ist gemacht um Performance zu maximieren und resourcen benutzung zu minimieren.

Ich habe meine Heizungssteuerung auf ATmega32 erst in C und als ich dann FreePascal entdeckt habe nochmal in Pascal geschrieben. Es nimmt sich in der Performance und Ressourcennutzung so gut wie nichts. Allerdings musste ich dann doch auf einen ATmega1284 (pinkombatibel) umsteigen, weil das Programmieren in Pascal so viel Spass gemacht hat, dass ich immer noch ein Menu (Stringkonstanten fressen Flash) und noch ein paar Gimmicks eingebaut habe.

Allerdings komme ich vom Assembler und weiß wie man einen Mikrocontroller programmieren sollte. Wenn jemand einen "Arduino" mit einem DS18S20 erstmal ein "sleep 1000" verpasst, um auf das Ende der Messung zu warten, und dann rumheult, dass der Controller zu langsam ist, ist es egal ob er das in C, "Arduino-C" oder Pascal programmiert. Oder wenn Leute denken, sie können Strings auf dem AVR genauso mit den Stringfunktionen verarbeiten wie am PC - ja sicher geht das, aber es frißt halt unendlich Ressourcen. Oder eine PT100-Kennlinie mit Floats als quadratische Gleichung berechnen - Lockup-Table ist Dein Freund, dann klappts auch in annehmbarer Zeit.

Ich fürchte, die meisten "Ressourcen-Probleme" am AVR, Arduino entstehen, weil die Leute glauben sie können die wie ihren Computer programmieren.

[pluto]

Oder wenn Leute denken, sie können Strings auf dem AVR genauso mit den Stringfunktionen verarbeiten wie am PC - ja sicher geht das, aber es frißt halt unendlich Ressourcen.

ich finde immer solche Aussagen im Internet sehr lustig, wenn da steht: ich verwende für Aufgabe XY ein String auf einen AVR.
Strings nutzte ich auf einen ESP, weil der hat genug speicher, aber ein AVR?
Habe heute endeckt: Es gibt sogar ein attiny mit 0,5 KB speicher....

Ich fürchte, die meisten "Ressourcen-Probleme" am AVR, Arduino entstehen, weil die Leute glauben sie können die wie ihren Computer programmieren.

An irgendetwas sollte man schon glauben.... aber davon auszugehen, dass das richtig ist, was man Programmiert nur weil es läuft, ist irgendwie nicht ganz richtig...

[Warf]

Allerdings komme ich vom Assembler und weiß wie man einen Mikrocontroller programmieren sollte. Wenn jemand einen "Arduino" mit einem DS18S20 erstmal ein "sleep 1000" verpasst, um auf das Ende der Messung zu warten, und dann rumheult, dass der Controller zu langsam ist, ist es egal ob er das in C, "Arduino-C" oder Pascal programmiert. Oder wenn Leute denken, sie können Strings auf dem AVR genauso mit den Stringfunktionen verarbeiten wie am PC - ja sicher geht das, aber es frißt halt unendlich Ressourcen. Oder eine PT100-Kennlinie mit Floats als quadratische Gleichung berechnen - Lockup-Table ist Dein Freund, dann klappts auch in annehmbarer Zeit.

Ich fürchte, die meisten "Ressourcen-Probleme" am AVR, Arduino entstehen, weil die Leute glauben sie können die wie ihren Computer programmieren.

Ich bin absolut kein fan von dem Arduino C, weil das versucht mit ner riesigen Bibliothek alles abzudecken. Ein Digital Write besteht aus mindestens zwei tabellenlookups was ziemlich viel zeit frisst.
Ich benutze daher Atmel Studio mit C++ und der avrlibc und nicht mehr. Außerdem kann man sich mit den ganzen C++ features echt austoben. Bei pascal ist man soweit ich weiß ja auf Objects beschränkt, und da fehlen mir doch einige features die C++ bietet (z.B. automatischer konstruktor/destruktor aufruf)

[MacWomble]

Wenn du Pascal so unzureichend findest, was machst du dann damit? C++ macht ohnehin viel mehr Spass.

[Timm Thaler]

...und da fehlen mir doch einige features die C++ bietet (z.B. automatischer konstruktor/destruktor aufruf)

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.

[pluto]

Den Du auf einem AVR an welcher Stelle brauchst?

Auch auf dem AVR Arbeite ich mit Klassen, zwar nicht in dem Umfang wie bei Lazarus aber ich tue es.
Diese Klassen werden natürlich NIE freigeben, wie den auch?

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

[Timm Thaler]

Strings nutzte ich auf einen ESP, weil der hat genug speicher, aber ein AVR?

Doch, natürlich. Man muss nur wissen wie man sie verwendet.

Anzeigen / Menüs für Textdisplays liegen bei mir im Flash und werden entweder direkt ans Display oder in den Displaybuffer geschrieben. Wenn man da die vorhandenen Stringfunktionen verwendet, in denen die Zeichen erstmal lustig im Ram hin- und herkopiert werden, fliegt einem das ganz schnell um die Ohren, egal ob C oder Pascal. Beim Versuch mehrere Menüs mit 4x20 Zeichen im Ram zu halten ist irgendwann out of memory.

Strings / Payload für nRF Sender werden in einen Buffer geschrieben. Aber die Payload ist eh nur 32 Byte lang.

Int-to-String, Festkomma-to-String mache ich mit eigenen Routinen, das ist nicht sonderlich schwer, spart aber einen Haufen Ballast. Zumal man auf dem AVR Float / Real eh weitgehend vermeiden sollte und sich für Festkomma was einfallen lassen muss. Das ist unter C genauso wie unter Pascal. Ada kann gut mit Festkomma rechnen, aber Ada hat wieder andere Macken.

[pluto]

Das ist unter C genauso wie unter Pascal. Ada kann gut mit Festkomma rechnen, aber Ada hat wieder andere Macken.

Soweit ich weiß, werden Festkomma Zahlen auf dem(per Software) AVR Simuliert, weil sie keine FPU(?) haben.
man kann aber trotzdem komplizierte Berechnungen machen.
Z.B. habe ich gesehen, wie der Sonnen auf und Untergang berechnet wird.

Auf dem AVR Arbeite ich nicht mit Strings sondern eher mit char test[].
jedoch muss ich an einigen stellen sprintf verwenden zwischendurch, was eigentlich unschön ist...
Geht aber.