Forum: Offtopic Warum Pascal/Delphi/Lazarus oft unbeliebt?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Yalu X. (yalu) (Moderator)


Lesenswert?

Max S. schrieb:
> nach den Meinungen hier im Forum programmieren hier eher 98% Prozent
> Betriebssysteme :)

Das sicher nicht. Aber du musst berücksichtigen, dass wir hier in einem
technisches Forum sind. Dazu später mehr, aber erst einmal ein paar
Worte zum – wieder einmal – unglücklichen  Diskussionsverlauf hier:

Du fragst im Thread-Titel, warum Pascal/Delphi/Lazarus oft unbeliebt
sei. Bevor du den anderen überhaupt ein Chance gibst, sich dazu zu
äußern, stellst du von vornherein klar, dass du keine der kommenden
Antworten akzeoptieren wirst:

Max S. schrieb:
> Ich finde nach wie vor, das Lazarus/Deplhi/PAscal unschalgbar für die
> meisten Anwendungen ist.

Wenn du eine sachliche Diskussion erwartest, warum lässt du sie dann
nicht erst einmal nach allen Seiten offen?

Wenn es dir nicht nur um die Diskussion, sondern tatsächlich um die
Beantwortung deiner Frage geht, hättest du besser sogar eine neutrale
Position eingenommen und die Diskussion nur moderiert. Ja, dazu muss man
kein offizieller Moderator sein. Jeder Forenteilnehmer, insbesondere der
Thread-Eröffner darf in diese Rolle schlüpfen, wenn im viel am Erfolg
der Diskussion liegt.

Durch das "Ich finde" kennzeichnest du deine Aussage immerhin als deine
persönliche Meinung, außerdem beschränkst du sie auf "die meisten
Anwendungen", so dass bis zu diesem Punkt evtl. noch eine halbwegs
sachliche Diskussion möglich gewesen wäre.

Aber schon bald kommt W.S. vorbei und deklariert deine Aussage als
unumstößlichen Tatsache:

W.S. schrieb:
> Auf dem PC ist sowohl Delphi als auch Lazarus schlichtweg unschlagbar

Anders ausgedrückt: Jeder, der auf dem PC etwas anderes als Delphi oder
Lazarus benutzt, ist einfach nur dumm.

Max S. schrieb:
> Insgesamt scheint es aber so zu sein, das sehr wohl noch eine Menge in
> Pascal programmieren nur die C Leute  lauter schreien

Du hast die Diskussion Pascal <-> C selber angefacht, und das schon in
deinem Eröffnungsbeitrag:

> Und alltägliche Tools wie der Totalcommander, zeigen auch, das solche
> Tools den der C Fans in nichts nachstehen.
> ...
> Immer wird darüber geredet, das C++ das auch könnte..nur ständig wenn
> ich ein in C++ geschriebenes Programm Installieren!! muss..müssen
> zusätzlich sogar oft Updates von der Microsoft Seite geladen werden!
> KOTZ!
> ...
> selbst wenn das C Programm mal kleiner ist..wird das mehr als
> vermasselt

Wolltest du tatsächlich erfahren, warum Pascal unbeliebt ist, oder
wolltest du vielmehr eine Bestätigung deiner eigenen schlechten Meinung
zu C/C++ erhalten?

Nach all dem musste ich bei deinem letzten Satz etwas schmunzeln:

> Wäre schön, wenn es sachlich bleiben könnte!


Max S. schrieb:
> Den nach wie vor, kann ich für die Win/LInux Porgrammierung keinen
> sinnvollen Grund sehen, warum man sich das antun sollte für 98& der
> Benutzer kommt man einfach mit Lazarus erheblich schneller ans Ziel.#

Wenn ich jetzt 100 Softwareentwickler aus meinem Bekanntenkreis fragen
würde, ob sie mit Lazarus schneller als mit anderen Tools sind, wäre die
Anzahl der positiven Antworten nicht 98, auch nicht 50, nicht einmal
zwei, sondern schlichtweg 0.

Da aber 100 Leute statistisch alles andere als repräsentativ sind, hast
du sicher 1 Million Leute dazu befragt ;-)

: Bearbeitet durch Moderator
von Max S. (maximus-minimus)


Lesenswert?

ähm..was ist den an Pascal im  µc Bereich nicht Hardwarenah genug?!?
Ich denke da ist kein nennenswerter Unterscief zu C.
Bei C ist nur der Vorteil der etwas kürzeren Schreibweise..also
nicht
a := a + b;

sondern a += a

Anosnten hast Du den vollen Bitzugriff in Pascal....wie gesagt, viele 
reden heir offenbar vom PAscal aus 1980 und vergleichen es mit C aus 
2018....
In Pascal gibt es SHL SHR (SHIFTEN) genauso wie das setzen einzelner 
Bits bzw Manipulation dieser

von Bernd K. (prof7bit)


Lesenswert?

Dr. Sommer schrieb:
> Wie wär's mit Xojo? Auch super portabel, mit einer intuitiven
> Anfängerfreundlichen Sprache.

Natives Kompilat? Statisch gelinkt? Vernünftige Sprache? Vernünftige 
Weltklasse-IDE mindestens so gut wie Lazarus? GUI-Builder mindestens so 
gut wie Lazarus?

von Max S. (maximus-minimus)


Lesenswert?

also den ersten Tag verlief die Diskussion irgendwie absolut 
problemlos..trotz des..wie Du meinst unglücklichen Titels...Bis dann 
wieder einige unpassende Beiträge kamen die die Stimmung angeheizt 
haben..und nicht gelöscht wurden..
egal..ich diskutieren hier auch nicht mit dem Mo..die Aufgabe des Mods 
sollte eher sein, sich neutral zu äußern oder  nur zu lenken.
Das das in diesem Forum nicht klappt..ist bekannt :-(

von Max S. (maximus-minimus)


Lesenswert?

ach ja...das Gleiche gilt natürlicha uch für Basic. Auch das erlaubt 
direkten Hardwarezugriff meines Wissens nach..

von Andreas B. (bitverdreher)


Lesenswert?

Ich finde, außer dem Beitrag von Webfehler geht es hier doch noch 
gesittet zu.
Aber es stimmt schon, es gehen viele Beiträge etwas am Thema vorbei.

Yalu X. schrieb:
> Max S. schrieb:
>> Ich finde nach wie vor, das Lazarus/Deplhi/PAscal unschalgbar für die
>> meisten Anwendungen ist.
>
> Wenn du eine sachliche Diskussion erwartest, warum lässt du sie dann
> nicht erst einmal nach allen Seiten offen?

Er hat seine Meinung geäußert (die ich im übrigen Teile). Er wurden ja 
auch andere Meinungen in gesitteter Form vorgetragen.
Es geht also schon.

Yalu X. schrieb:
> Aber schon bald kommt W.S. vorbei und deklariert deine Aussage als
> unumstößlichen Tatsache:

Er kam etwas später und ist nicht der TO. Es war auch die Reaktion auf 
Beiträge, die sich absolut negativ über Lazarus/Pascal äußerten und es 
offensichtlich noch nie benutzt haben.

von Carl D. (jcw2)


Lesenswert?

Worin liegt eigentlich das Problem?
Hat irgendjemand verboten Pascal zu benutzen?
Oder hat sich jemand als Opfer der Bösen hochstilisiert, die lieber auf 
Pascal verzichten?

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Max S. schrieb:
> ähm..was ist den an Pascal im  µc Bereich nicht Hardwarenah genug?!?

Es gibt für praktisch jeden µC mindestens einen verwendbaren C-Compiler. 
Oft ist das eine gcc-Variante, d.h. ein freier und gut dokumentierter 
Compiler, mit häufigen Aktualisierungen (auch wenn sich die nicht in 
jeder µC-Architektur niederschlagen, das hängt vom "Maintainer" der 
jeweiligen Portierung ab).

Die Verfügbarkeit von Pascal-Compilern sieht da dann doch etwas anders 
aus.

Beispielsweise habe ich noch nichts von einem Pascal-Compiler für die 
msp430-Reihe gehört.

Das scheint also doch etwas andere Hintergründe zu haben, als daß 
"C-Apologeten" einfach nur lauter schreien würden, wie hier im Thread 
suggeriert wurde.

Dazu kommt, daß die Fähigkeit, C-Code zu verstehen (d.h. mit der Syntax 
klarzukommen) auch die Grundlage für einige andere recht verbreitete 
Programmiersprachen ist, C++, Java, ECMAscript und nicht zuletzt C# aus 
Microsofts .Net-Welt.

Eine pascal-artige Syntax gibt es auch bei anderen Programmiersprachen, 
Modula-2 und Oberon. Abgesehen von sehr kleinen Nischen (die meistens in 
akademischen Kreisen zu finden sind), kann man nicht behaupten, diese 
Sprachen würden weitverbreitete Anwendung finden. Immerhin, es soll 
einen Modula-2-Compiler für MCS-51 geben.

Wenn ich mit meinen Einschätzungen danebenliege, mögen doch bitte 
entsprechende Compiler/Toolchains für verschiedene µC-Architekturen 
aufgelistet werden.

Danke.

von Max S. (maximus-minimus)


Lesenswert?

auch das gleiche beispiel wie wenn gezielt nach einer Funktion gesucht 
wird die in Pascal fehlt..Die Mehrheit wird mit AVR und ARM arbeiten.
Klar, kann man jetzt eine Liste selten genutzter Controller suchen, 
weshalb Pascal oder Java keine gute Sprache sind.
Aber wie gesagt..es betrifft kaum jemanden.
Die meisten lassen sich durch die Massen mitreisen, mit eben solchen 
Argumenten wie von Dir vorgebracht.
Und evtl liegt genau in Deinem anderen Argument ..das Problem..
Das hier ist ein technisches Forum(Nerd Forum) das bedeutet, wenn 
Newcommer fragen was eine gute Sprache ist kommen Nerd Antworten..
Das wäre als wenn Tante Trude fragt, welches Betriebssystem das 
ist,welches sie nehmen soll..und ihr alle Nerds Linux empfehlen würde...

Schlussendlich macht Trude sich das Leben unnötigt schwer, weil sie in 
die irre geführt wurde.
Mit Windows wäre sie wunschlos glücklich, alles würde laufen und alles 
wäre ganz einfach..jetzt fragt Trude ständig ihren Enkel, weil nie was 
von der Stange funktioniert.weil sie ja das "Beste" System nutzt.

von Andreas B. (bitverdreher)


Lesenswert?

Die Programmierspache von der Stange für uC ist halt mal C, nicht 
Pascal.

von Andreas B. (bitverdreher)


Lesenswert?

Ah, ja, was den Seitenhieb auf Linux betrifft: Tante Trude kommt damit 
meist besser klar als Windows. Selbst schon oft erlebt.
Aber das ist am Thema vorbei.

von Bernd K. (prof7bit)


Lesenswert?

Max S. schrieb:
> Schlussendlich macht Trude sich das Leben unnötigt schwer, weil sie in
> die irre geführt wurde.
> Mit Windows wäre sie wunschlos glücklich

Das genaue Gegeteil ist der Fall wie aus allen in der Vergangenheit 
durchgeführten deratigen Versuchen im Endergebnis ersichtlich wurde.

Aber herzlichen Glückwunsch daß Du es endlich geschafft hast in diesem 
Thread auch noch ein Anti-Linux Troll Posting einzuwerfen, hat lange 
genug gedauert.

Ich glaube jetzt kann abgesperrt werden bevor es vollkommen außer 
Kontrolle gerät.

: Bearbeitet durch User
von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

Bernd K. schrieb:
> Aber herzlichen Glückwunsch daß Du es endlich geschafft hast in diesem
> Thread auch noch ein Anti-Linux Troll Posting einzuwerfen, hat lange
> genug gedauert.

Jepp, ist unnötig und hat hier auch nichts verloren.

> Ich glaube jetzt kann abgesperrt werden bevor es vollkommen außer
> Kontrolle gerät.

Nein, es fehlt noch Eagle vs. KiCad ;-)

Zum Thema:
Ein wesentlicher Vorteil für diejenigen, die in C/C++ programmieren, ist 
einfach die um mehrere Größenordnungen größere Code-Basis gerade im 
OS-Bereich, an der man sich bedienen kann.

Ein Anfänger findet eben für C deutlich mehr Beispiele und 
Implementationen als für Pascal.

Das ist schlicht der "der Teufel scheisst auf den größten Haufen"-Effekt 
und ganz unabhängig von der Qualität einer Programmiersprache.

Ich programmiere alles GUI-mäßige unter Tcl/Tk - ich brauche zur 
GUI-Entwicklung nicht mal eine IDE geschweige denn einen 
Compilierzyklus, sondern kann im laufenden Programm alles so einrichten, 
bis es passt.

Tcl führt gegenüber Python auch eher ein Nischendasein, aber ich komme 
damit bestens zu Recht. Mit einem passenden kleinen Interpreter kann man 
sogar direkt auf µC Tcl-Programme ausführen, so dass wirklich nur 
zeitkritische Sachen hier in C geschrieben werden.

Mit Python konnte ich mich dagegen nie so wirklich anfreunden - liegt 
aber vermutlich einfach auch daran, dass ich mich unter Tcl/Tk bewege 
wie ein Fisch im Wasser ;-)

Lazarus sieht doch ganz gut aus - wenn man damit gut zurecht kommt, ist 
das doch perfekt.

Mein Fazit ist jedenfalls: ob eine Sprache in einer Nische verweilt, 
liegt weniger an der Sprache als daran, dass eine bereits größere 
Verbreitung dazu führt, dass Neulinge sich auch eher damit beschäftigen, 
was den Effekt noch verstärkt. Wäre Tcl etwas früher dagewesen, würde 
vielleicht Python  das Nischendasein fristen - ganz unbesehen der 
jeweiligen Vor- und Nachteile.

Die Masse macht's.

Und das Phänomen gibt es ja nicht nur im Programmiersprachenbereich.

von Max S. (maximus-minimus)


Lesenswert?

danke, sowas ist eine Meinungsäußerung eines Mods, die die Stimmung 
nicht weiter anheizt sondern eher wieder etwas Ruhe in eine aufgeheizte 
Diskussion bringt, trotz einer eigenen Meinung, die aber nicht 
polarisiert

: Bearbeitet durch User
von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Also ich fand Turbo Pascal schon cool, und wer damals MacOS 4.x bis 
MacOS 7.x programmiert hat, kam an Pascal überhaupt nicht vorbei, wenn 
er mit MPW programmiert hat - alles bei diesen MacOS war auf Pascal 
zugeschnitten. Und natürlich wurden auch Treiber (Systemerweiterungen) 
unter Pascal programmiert. Und unbeliebt oder nicht hat Apple gar nicht 
interessiert, man nimmt Pascal - Punkt.

Das hat sich mit PowerPC und dann Intel geändert und Turbo Pascal gibt 
es nicht mehr - was wirklich schade ist. Auch mit Turbo konnte man schön 
hardwarenah programmieren.

von Uhu U. (uhu)


Lesenswert?

Max S. schrieb:
> danke, sowas ist eine Meinungsäußerung eines Mods, die die Stimmung
> nicht weiter anheizt sondern eher wieder etwas Ruhe in eine aufgeheizte
> Diskussion bringt, trotz einer eigenen Meinung, die aber nicht
> polarisiert

Moderator - von lateinisch moderare ‚mäßigen‘, ‚steuern‘, ‚lenken‘

von G. P. (gelegenheitsprogramm)


Lesenswert?

Bernd K. schrieb:
> Dr. Sommer schrieb:
>> Wie wär's mit Xojo? Auch super portabel, mit einer intuitiven
>> Anfängerfreundlichen Sprache.
>
> Natives Kompilat? Statisch gelinkt? Vernünftige Sprache? Vernünftige
> Weltklasse-IDE mindestens so gut wie Lazarus? GUI-Builder mindestens so
> gut wie Lazarus?

Hat Dr. Sommer mal einen Blick auf die Webseite von Xojo geworfen? 
Sicher nicht, sonst wäre ihm aufgefallen, dass dies ein 
Abo-Software-Modell ist, das jedes Jahr mindestens 299 $ in der 
Minimalvariante haben möchte.

Dagegen ist eagle mit seinen 130 EUR/Jahr direkt ein Schnäppchen.

;)

Beitrag #5472525 wurde vom Autor gelöscht.
von G. P. (gelegenheitsprogramm)


Lesenswert?

Chris D. schrieb:
> Ich programmiere alles GUI-mäßige unter Tcl/Tk - ich brauche zur
> GUI-Entwicklung nicht mal eine IDE geschweige denn einen
> Compilierzyklus, sondern kann im laufenden Programm alles so einrichten,
> bis es passt.

Na ja, TCL/TK Scheint mir aber auch kein leuchtendes Beispiel für 
Anfängerfreundlichkeit oder Gelegenheitsbenutzer zu sein:

https://wiki.tcl.tk/1048
1
proc ilist { {begin {.}} {listf {winfo children}} {maxdepth {100}} {ident {0}} } {
2
    if {$maxdepth <1} return
3
    set de {}; set o {}
4
    for {set i 0} {$i < $ident} {incr i} {append de {   }}
5
    foreach i [eval "$listf $begin"] {
6
        append o "$i "
7
        #puts "$de $i"
8
        append o [ilist $i $listf [expr $maxdepth-1] [expr $ident +1]]
9
    }
10
    return $o

Mein Bauchgefühl sagt mir da eher, lass gut sein.

;)

von Yalu X. (yalu) (Moderator)


Lesenswert?

Im folgenden, etwas länglichen Text steht einiges Positives über Pascal
und auch ein wenig über die Hürden bei dessen Einsatz in technischen
Anwendungen. Diejenigen Pascalianer, die sich der positiven Aspekte
sowieso bewusst sind und die nichts über Hürden hören, sondern gleich
zur Tat schreiten und diese niederwalzen wollen, lesen bitte unten
weiter bei "#########".

Ich lese aus den Aussagen der Pascal-Benutzer hier im Thread im
Wesentlichen drei Dinge heraus, wo sie  bei Pascal in Verbindung mit den
Entwicklungsumgebungen Delphi bzw. Lazarus Vorteile sehen:

- Lesbarkeit des Codes

- Typsicherheit

- GUI-Entwickung

Was die Lesbarkeit betrifft, zeigt die Diskussion, dass das ein sehr
subjektives Kriterium ist, über das man diskutieren kann, aber nicht
streiten sollte.

Typsicherheit ist eine Eigenschaft der Sprache, und da ist Pascal sicher
besser aufgestellt als C++ oder gar C. Gemessen an der Gesamtheit aller
Programmiersprachen belegt aber auch Pascal keinen der obersten Plätze.

Mit GUI-Entwicklung beschäftige ich mich kaum, deswegen ist das für mich
persönlich kein starkes Kriterium bei der Auswahl einer Sprache oder
einer Entwicklungsumgebung. Aus dem, was ich aber von Leuten gehört
habe, die sich intensiver mit dem Thema beschäftigen, scheinen Delphi
und Lazarus diesbezüglich tatsächlich top zu sein. Das ist allerdings
nicht primär ein Verdienst der Sprache Pascal, sondern der mit den
Entwicklungsumgebungen mitgelieferten Tools, Bibliotheken und Frameworks
sowie der sauberen Integration derselben zu einem Gesamtsystem.


Da wir uns hier in einem technischen Forum befinden, spiegelt die
Nutzerschaft kaum die Gesamtheit aller Softwareentwickler wider. Bspw.
werden hier kaum Entwickler anzutreffen sein, die im Bankenwesen und dem
betriebswirtschaftlichen Bereich tätig sind.

Anders als in den letztgenannten Bereichen nimmt die GUI-Entwicklung im
technischen Bereich nur einen relativen geringen Anteil am gesamten
Entwicklungsaufwand ein. Hier stehen andere Themen im Vordergrund wie

- Steuerungs- und Regelungstechnik
- Sensor- und Antriebstechnik
- Automatisierungstechnik, Robotik
- Simulation
- Bildverarbeitung
- u.v.m.

Ähnlich wie in der GUI-Entwicklung wird auch hier das Rad nicht ständig
neu erfunden, sondern es werden jede Menge Bibliotheken, Frameworks,
Codegenerierungs-, Debug- und Profilingtools eingesetzt, die aber aus
historischen Gründen größtenteils oft nur für C und C++ verfügbar sind.

Ich selber beschäftige mich neben anderen Dingen mit Bildverarbeitung.
Da gibt es im Open-Source-Bereich vor allem die OpenCV und daneben noch
einige kommerzielle Bibliotheken. Alle davon sind für den Einsatz mit C,
C++ und teilweise Pythen gemacht. Für Pascal scheint es außer ein paar
wenig erfolgreichen Versuchen, Wrapper für die OpenCV zu erstellen, so
gut wie nichts zu geben.

Nicht arg viel besser sieht es mit Bibliotheken für Numerik und lineare
Algebra. Das sind aber Dinge, die für etwas komplexere Anwendungen in
der Automatisierungstechnik zwingend benötigt werden. Gibt es für Pascal
bspw. ein Pendant zur Eigen-Bibliothek?

  http://eigen.tuxfamily.org/

Die Open-Source-Bewegung hält seit einigen Jahren auch Einzug in die
Robotik. Ein Großteil dieser Software baut mittlerweile auf ROS

  http://www.ros.org/
  https://rosindustrial.org/

auf, das neben einem Softwareframework eine Vielzahl von Bibliotheken,
Entwicklungswerkzeugen und Diagnosetools enthält. Auf deren Webseite
wird die Programmiersprachenunabhängigkeit als eines der großen Ziele
angegeben, und es gibt bereits Client-Libraries für mehr als ein Dutzend
(teils recht exotischer) Sprachen:

  http://wiki.ros.org/Client%20Libraries

Die Liste der experimentellen Implementierungen enthält sogar Exoten wie
Julia, Haskell und Pharo. Pascal sucht man jedoch vergeblich.

Warum? Gibt es keine Pascalianer, die Robotik machen? Ich weiß es nicht.

Nicht alle technischen Anwendungen basieren auf komplexen Algorithmen
und kommen deswegen oft auch ohne die Verwendung von Bibliotheken aus.
Das sind vor allem Anwendungen, die auf kleinen Mikrocontrollern laufen.
An die Stelle komplizierter Berechnungen treten hier hardwarenahe Dinge
wie I/O-Operationen, Interrupts und dergleichen. Gleichzeitig wird
versucht, möglichst viel Funktionalität auf engstem Raum (Flash, RAM) zu
vereinen.

Rein technisch spricht überhaupt nichts gegen den Einsatz von Pascal auf
kleinen µC. So gibt es für den AVR immerhin drei verschiedene Compiler,
die ich mir vor einiger Zeit auch einmal näher angeschaut habe (ich bin
ja schließlich keiner von den verbohrten C-Fanboys ;-)):

- mikroPascal PRO for AVR

- AVRco

- AVR-FPC (Free Pascal)

Bei mikroPascal hatte ich den Eindruck, dass das in Wirklichkeit ein C
im Pascal-Gewand ist. Viele Dinge, die Pascal gegenüber C auszeichnen,
wurden einfach weggelassen oder C-ähnlich umdefiniert. So fehlen bspw.
ein echter Boolean-Typ, und es sind keine verschachtelten Funktions- und
Prozedurdefinitionen möglich. Strings sind wie in C nullterminiert, die
Stringfunktionen der Bibliothek entsprechen fast genau ihren C-Pendants.
Pointervariablen können direkt numerische Werte zugewiesen werden usw.

Was letztendlich bleibt, ist im Wesentlichen die Syntax von Pascal. Wenn
man nicht gerade eine Allergie gegen geschweifte Klammern hat, fällt mir
kein Grund ein, warum man diesen Compiler anstelle eines C-Compilers
benutzen sollte


AVRco hat sogar die Pascal-Syntax geändert, indem die BEGINs in IF- und
Schleifenanweisungen wegfallen und das END durch ENDIF, ENDFOR usw.
ersetzt wird. Lediglich für die Rümpfe von PROGRAM- PROCEDURE- und
FUNCTION-Definitionen wird BEGIN/END noch benötigt. Das kommt sicher den
BEGIN/END-Gegnern entgegen, erschwert aber das Testen von – ansonsten
portablen – µC-Codefragmenten auf dem PC.

Auch beim AVRco wurden etliche Pascal-Features weggelassen und dafür
C-Features hinzugefügt. So kann man bspw. ähnlich wie in C schreiben
(ban beachte aber den feinen Unterschied bei --):

  ptr1^++ := ptr2^++    (in C: *ptr1++ = *ptr2++; )
  ptr1^-- := ptr2^--    (in C: *--ptr1 = *--ptr2; )

Obwohl dieser Compiler von den dreien auf mich den besten Eindruck
macht, sehe ich auch hier ich keine wirklichen Vorteile gegenüber C.


Free Pascal implementiert – bis auf Dinge, die auf dem AVR aufgrund
seiner Hardwarerestriktionen nicht sinnvoll machbar sind – fast den
gesamten Sprachumfang, der auch auf der PC-Version verfügbar ist. Das
erleichtert natürlich den Vorabtest von Softwarefragmenten auf dem PC.
Die Codegenerierung steckt aber noch arg in den Kinderschuhen. So ist
der erzeugte Assemblercode meist nicht viel besser als der vom GCC mit
komplett ausgeschalteter Optimierung (-O0). Am auffälligsten hierbei
ist, dass Variablen aus dem RAM oft unnötigerweise mehrmals kurz
hintereinander in Register geladen werden. Vielleicht hat sich das seit
meinen Tests vor ca. 3 Monaten geändert. Um das festzustellen, müsste
ich den Compiler aus den aktuellen Sourcen neu bauen, was ein weiteres
Hindernis darstellt.


Das oben Geschriebene soll verdeutlichen, dass es Ingenieure und
Techniker mit Pascal nicht ganz leicht haben. Sicher würden sie bei der
GUI-Entwicklung etwas Zeit einsparen. Besteht aber eine typische
technische PC-Anwendung bspw. aus 90% Berechnungen und 10% GUI, hat man
drei Alternativen:

1. 100% der Software in Pascal: Bei 90% kommt man nicht in den Genuss
   existierender Bibliotheken, was den Gesamtaufwand stark in die Höhe
   treibt.

2. Die 90% Berechnungen in C++ und das GUI in Pascal: Man spart bei dem
   GUI-Teil Entwicklungsaufwand ein, allerdings entsteht bei der
   Integration der beiden Softwareteile zusätzlicher Aufwand, ebenso bei
   der späteren Softwarewartung. Man muss also sehr genau abwägen, ob
   der Schuss am Ende nicht nach hinten los geht. Was geschieht bspw.,
   wenn irgendwann für einen der beiden Compiler das ABI geändert wird?

3. 100% der Software in C++: Der Aufwand wird u.U. etwas höher sein als
   in (2), dafür ist das Ergebnis aber aus einem Guss, und die Gefahr
   von späteren Überraschungen ist nicht so groß. Und so arg schlecht
   und unbenutzbar sind ja die GUI-Frameworks wie bspw. Qt auch wieder
   nicht. Mit etwas Übung wird auch damit in akzeptabler Zeit ein GUI
   hinbekommen.


Das alles hat aber weder mit der Sprache Pascal an sich (die finde ich
gar nicht mal so schlimm) noch mit der Entwicklungsumgebung (die sogar,
was Delphi/Lazarus betrifft, ziemlich gut ist) zu tun, sondern an dem
ganzen Drumherum, für das weder der Niklaus Wirth noch die Delphi-/
Lazarus-/FPC-Entwickler etwas können.

Um eine Programmiersprache populär zu machen, genügt es halt nicht,
schöne Reden zu schwingen und die Alternativen schlecht zu machen. So
ist es Microsoft immerhin gelungen, C# innerhalb von ein paar Jahren in
die Top 5 der populärsten Programmiersprachen zu heben und das, obwohl
C# von den Sprachfeatures her weder viel Neues noch viel Besonderes
bietet. Der Erfolg kommt vielmehr daher, dass neben der Sprache und der
IDE viele weitere Dinge wie Bibliotheken und Frameworks (nicht nur für
GUIs), jede Menge zusätzliche Entwicklungstools und nicht zuletzt die
weitgehend nahtlose Zusammenführung mit Varianten bereits bekannter
Sprachen (Visual Basic, Python, OCaml) bereitgestellt wurden.

Es ist natürlich klar, dass die relativ kleine Firma Embarcadero oder
die Entwicklergruppe von Lazarus/FPC diesbezüglich nie so viel reißen
kann wie der Branchenriese Microsoft. Dass aber auch Open-Source-
Entwicklungstools sehr erfolgreich sein, zeigt GCC. Ich schätze, C++
wäre nicht einmal halb so populär wie es heute ist, wenn es den GCC
nicht gäbe. Nicht umsonst ist das GCC-Team maßgeblich an der Einführung
von Neuerungen und dem ISO-Normumgsgremium beteiligt.

#########

Also, ihr Pascalianer da draußen: Hört auf, hier im Forum weiter
erfolglos für eure Sprache zu werben, sondern setzt euch hin und macht
Nägeln mit Köpfen und schreibt

- einen Wrapper für OpenCV

- eine Implementierung der Eigen-Bibliothek

- einen besseren Codegenerator für den AVR-FPC (wobei es wahrscheinlich
  besser wäre, die LLVM-Unterstützung durch den FPC voranzutreiben, was
  gleich mehrere Fliegen auf einmal erschlagen würde)

- evtl. noch ein paar Spracherweiterungen für Zero-Cost-Abstractions,
  wie sie in den letzten Jahren C++ deutlich aufgewertet haben

- eine Client-Library für ROS

- ... (andere haben sicher noch weitere Vorschläge)

Dann wird aus Pascal trotz seines hohen Alters auch im technischen
Bereich noch einmal eine richtig frische und runde Sache, und ich wäre
der letzte, der sich weigern würde, das Ganze auch auszuprobieren.

von Karl (Gast)


Lesenswert?

Da es die C-Freaks mit ihrem Rumgetrolle dankenswerterweise geschafft 
haben, dass der Lazarus / Freepascal Thread im Offtopic gelandet ist, 
hier mal ein paar technische Antworten auf dort aufgetauchte Fragen:

Autor: Andreas B. (bitverdreher)
Datum: 01.07.2018 10:03
>> Also für uC Programmierung ist Pascal meiner Meinung nach weniger
geeignet. Das mag bei den 32bit Controllern anders sein, aber für 8-bit
Controller braucht Pascal zu viel Ressorcen. Da habe ich es außerdem
auch ganz gern hardwarenah und kontrolliere jedes Bit.

Au contraire. Ich habe eine Heizungssteuerung mit Atmega32 von C auf Fpc 
übertragen, und ich kann Dir versichern, Du irrst. Nicht nur setzt Fpc 
I/O Operationen mit sbi / cbi bzw. in / out korrekt und effizient um, 
man kann damit auch so Sachen machen wie bitweise Arrays, und bekommt 8 
Booleans in ein Byte, welche dann korrekt mit sbr / cbr gesetzt und mit 
sbrs / sbrc gelesen werden. Das bekomme ich in Assembler nicht besser 
hin.

Voraussetzung ist Kompilierung mit -o3 und den aktuellen Trunk 3.1.x 
verwenden.

von Karl (Gast)


Lesenswert?

Autor: Max S. (maximus-minimus)
Datum: 01.07.2018 10:08
>> Bei C ist nur der Vorteil der etwas kürzeren Schreibweise..also
nicht
>> a := a + b;
>> sondern a += a

Natürlich geht unter Lazarus / Fpc auch sowas:

inc(a);
a += b;
a -= b;

Wenn das bei Dir nicht geht, kannst Du das unter den 
Kompilereinstellungen einschalten.

von Karl (Gast)


Lesenswert?

Autor: Yalu X. (yalu) (Moderator)
Datum: 01.07.2018 15:50
>> Nicht arg viel besser sieht es mit Bibliotheken für Numerik und lineare
Algebra. Das sind aber Dinge, die für etwas komplexere Anwendungen in
der Automatisierungstechnik zwingend benötigt werden. Gibt es für Pascal
bspw. ein Pendant zur Eigen-Bibliothek?

Wenn Du wirklich daran Interesse hast, solltest Du die Frage vielleicht 
nicht hier, sondern im Fpc Forum stellen. Üblicherweise gibts da einige 
kompetente Leute, die Dir das ziemlich sicher beantworten können.

Ich habe es selbst noch nicht gemacht, da nicht benötigt, aber auch die 
Einbeziehung von C Libs in Pascal soll wohl machbar sein.

>> einen besseren Codegenerator für den AVR-FPC

Auch hier nochmal: Nimm die aktuelle 3.1.x aus dem Trunk, bei Avr 
embedded passierte in den letzten Monaten viel, welches nicht in den 
alten Versionen drin ist.

Und für die Installation sowohl unter Windows als auch unter Linux sei 
fpcupdeluxe angeraten, gibt es auch schon fertig kompiliert. Damit kann 
man verschiedene Versionen parallel installieren, Lazarus und Fpc 
aktuell halten und die verschiedenen Crosscompiler für Win, Linux, Linux 
auf Arm, Arm embedded, Avr embedded bauen.

Leider sind die Lazarus / Fpc Versionen in den Linux Repos nicht sehr 
aktuell.

von Webfehler (Gast)


Lesenswert?

Sag mal wieso antwortest du nicht im Originalthread, ist das zu 
kompliziert für Pascalnutzer?

von Sven K. (quotschmacher)


Lesenswert?

Karl schrieb:
> bitweise Arrays, und bekommt 8
> Booleans in ein Byte

hat mich jetzt keine minute gekostet, ein (sogar mehrere) pendant(s) in 
c zu finden: 
https://electronics.stackexchange.com/questions/200055/most-efficient-way-of-creating-a-bool-array-in-c-avr

von Gäähhnn (Gast)


Lesenswert?

Ein neuer Anlauf des Opferverbands Blaise.

von Hugo E. (Gast)


Lesenswert?

Webfehler schrieb:
[..]

lt. DUDEN:

Web­feh­ler, der

Wortart: Substantiv, maskulin

Worttrennung: Web|feh|ler

BEDEUTUNGSÜBERSICHT
- falsch gewebte Stelle in einer Webarbeit; Fehler im Gewebe
- (umgangssprachlich) von vornherein vorhandener,
  nicht zu behebender Fehler, mit dem jemand, etwas behaftet ist

von Max S. (maximus-minimus)


Lesenswert?

naja..das das Thema..warum auch immer in Offtopic gelandet ist, spielt 
es auch keine große Rolle mehr.
Schon merkwürdig dieses Forum...
@Autor: Sven A.
Was willst Du uns jetzt sagen?!
Hat jemand behauptet das es nicht ginge?!

von Andreas B. (bitverdreher)


Lesenswert?

Karl schrieb:
> Voraussetzung ist Kompilierung mit -o3 und den aktuellen Trunk 3.1.x
> verwenden.

Das mag ja alles sein, aber wozu ist das gut? 90% aller Bibliotheken im 
Internet für uC sind in C geschrieben. Ich habe daher keine Veranlassung 
uCs in Pascal zu programmieren.

Yalu X. schrieb:
> Aus dem, was ich aber von Leuten gehört
> habe, die sich intensiver mit dem Thema beschäftigen, scheinen Delphi
> und Lazarus diesbezüglich tatsächlich top zu sein. Das ist allerdings
> nicht primär ein Verdienst der Sprache Pascal, sondern der mit den
> Entwicklungsumgebungen mitgelieferten Tools, Bibliotheken und Frameworks
> sowie der sauberen Integration derselben zu einem Gesamtsystem.

Das ist der Punkt. Von mir aus kann Lazarus auch mit einer anderen 
Programmiersprache laufen. Daher habe ich bei meiner Argumentation auch 
immer von Lazarus/Pascal gesprochen. Mir geht es mehr um das RAD, was 
mit Lazarus/Pascal super umgesetzt wurde.

von Sven K. (quotschmacher)


Lesenswert?

Karl schrieb:
> Ich habe eine Heizungssteuerung mit Atmega32 von C auf Fpc
> übertragen, und ich kann Dir versichern, Du irrst. Nicht nur setzt Fpc
> I/O Operationen mit sbi / cbi bzw. in / out korrekt und effizient um,
> man kann damit auch so Sachen machen wie bitweise Arrays, und bekommt 8
> Booleans in ein Byte, welche dann korrekt mit sbr / cbr gesetzt und mit
> sbrs / sbrc gelesen werden.

Max S. schrieb:
> Was willst Du uns jetzt sagen?!
> Hat jemand behauptet das es nicht ginge?!

wurde zumindest als vorteil von fpc dargestellt, obwohl es unter c 
ebenso möglich ist.

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

G. P. schrieb:
> Na ja, TCL/TK Scheint mir aber auch kein leuchtendes Beispiel für
> Anfängerfreundlichkeit oder Gelegenheitsbenutzer zu sein:
>
> https://wiki.tcl.tk/1048
>
>
1
> proc ilist { {begin {.}} {listf {winfo children}} {maxdepth {100}} 
2
> {ident {0}} } {
3
>     if {$maxdepth <1} return
4
>     set de {}; set o {}
5
>     for {set i 0} {$i < $ident} {incr i} {append de {   }}
6
>     foreach i [eval "$listf $begin"] {
7
>         append o "$i "
8
>         #puts "$de $i"
9
>         append o [ilist $i $listf [expr $maxdepth-1] [expr $ident +1]]
10
>     }
11
>     return $o
12
>
>
> Mein Bauchgefühl sagt mir da eher, lass gut sein.

Und wie so oft täuscht das Bauchgefühl :-)

Man kann in jeder Sprache Beispiele konstruieren, die erst einmal 
undurchsichtig erscheinen - und wenn die dann auch noch unglücklich 
formatiert und schlecht gemacht sind, sieht das natürlich wild aus.

Tatsächlich ist die Tcl-Grammatik aber sehr einfach und orthogonal 
aufgebaut. Einfach mal die Anfängertutorien anschauen :-)

Aber das gehört hier alles nicht her und war nur ein Beispiel dafür, 
dass man auch jenseits des "Mainstreams" glücklich werden kann.

: Bearbeitet durch Moderator
von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Yalu X. schrieb:
> - eine Implementierung der Eigen-Bibliothek

Das nutzt doch komplexe Techniken der Metaprogrammierung (Expression 
templates...). Geht das in Pascal?

von Markus M. (Firma: EleLa - www.elela.de) (mmvisual)


Lesenswert?

Ich mag Lazarus - für PC Programme/GUI/Datenbanken
Ich mag C(++) für µC
Strukturierter Text für PLC Steuerungen (ist Pascal ähnlich)

Und das schon seit fast 20 Jahren und auch für sehr große Projekte.

Vor 20 Jahren waren GUI Programmierung, bzw. das Handling in C eine 
mittlere Katastrophe, was mit den heutigen modernen Sprachen nicht 
vergleichbar ist. Damals war Delphi darin der absolute Platzhirsch - 
nach wie vor ist/hat Lazarus eines der führenden GUI Editoren um sehr 
einfach und schnell komplexe GUI Strukturen designen zu können - daher 
habe ich nach wie vor kein Bedürfnis die Sprache zu wechseln.
Abgesehen davon ist in der EXE alles drin und habe keine "DLL Probleme" 
wegen dynamischen Bibliotheken.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Markus M. schrieb:
> Abgesehen davon ist in der EXE alles drin

Das heißt wenn es (Sicherheits!) Updates an den Bibliotheken gibt müssen 
alle Pascal/Delphi/Lazarus-Programme neu kompiliert werden? Was wenn der 
Source-Code nicht mehr vorliegt? Gerade unter Linux sind doch 
Abhängigkeiten kein Problem dank Paketmanager. In C und C++ kann man 
auch alles statisch linken - aber gerade das will man eigentlich nicht.
Kann Delphi/Lazarus eigentlich reaktive GUI's, also solche deren Fenster 
man beliebig größer/kleiner ziehen kann und deren Aufbau sich 
entsprechend anpasst, und die man so auch auf sehr hochauflösenden 
Monitoren nutzen kann mit entsprechendem Font-Rendering?

von (prx) A. K. (prx)


Lesenswert?

Niklas G. schrieb:
>> Abgesehen davon ist in der EXE alles drin
>
> Das heißt wenn es (Sicherheits!) Updates an den Bibliotheken gibt müssen
> alle Pascal/Delphi/Lazarus-Programme neu kompiliert werden?

Updates von Libs sind ein zweischneidiges Schwert.

- Hat man sie im EXE drin, ist es wie von dir beschrieben nötig, das EXE 
gelegentlich zu aktualisieren, obwohl die Kernanwendung nicht betroffen 
ist. Dafür betrifft ein Update aber nur exakt diese eine Anwendung, und 
die wurde in dieser Kombination vom Entwickler/Hersteller getestet.

- Hat man sie nicht im EXE drin, sondern als separate Libs, am Ende 
vielleicht sogar für alle EXEs auf der Maschine, dann sind Updates 
dieser Libs eine leicht riskante Affäre und beeinflussen die gesamte 
Maschine, mit entsprechenden Test, verlängerter Downtime etc. Denn 
manchmal passt eine alte App nicht zur neuen Lib. Ergebnis: never change 
a running system, Updates gibts nur wenn Ostern und Pfingsten zusammen 
fallen.

: Bearbeitet durch User
von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

Markus M. schrieb:
> Abgesehen davon ist in der EXE alles drin und habe keine "DLL Probleme"
> wegen dynamischen Bibliotheken.
Und nochmal, weil es offenbar noch nicht oft genung angesprochen wurde:
Das kann man auch mit C und C++, nennt sich statisches Linken und ist 
ueberhaupt kein Problem. Man muss den Tools nur die richtigen Flags 
mitgeben. Funktioniert wunderbar. Ist nur halt nicht das 
default-setting.

Niklas G. schrieb:
> Das heißt wenn es (Sicherheits!) Updates an den Bibliotheken gibt müssen
> alle Pascal/Delphi/Lazarus-Programme neu kompiliert werden?
Ja, ist bei C/C++ aber nicht anders, wenn statisch gelinkt.

Niklas G. schrieb:
> Was wenn der Source-Code nicht mehr vorliegt?
Pech gehabt. Wie bei C/C++ auch, wenn statisch gelinkt.

Ich versuche mir gerade vorzustellen, wie gross die .exe von aktuellen 
Spielen waere, wenn man die statisch linken wuerde... und wie sich die 
Spieler auf updates freuen, weil sie dann jedes mal x GB downloaden 
muessen.

Klingt jetzt etwas uebertrieben, aber sowas sollte man auch bedenken.

von Andreas B. (bitverdreher)


Lesenswert?

Niklas G. schrieb:
> Kann Delphi/Lazarus eigentlich reaktive GUI's, also solche deren Fenster
> man beliebig größer/kleiner ziehen kann und deren Aufbau sich
> entsprechend anpasst, und die man so auch auf sehr hochauflösenden
> Monitoren nutzen kann mit entsprechendem Font-Rendering?

Leider nicht, das müßte man sich selbst zurechtbasteln. Aber ich habe 
auch noch keine Programme gesehen, die das beherrschen.

Kaj G. schrieb:
> und wie sich die
> Spieler auf updates freuen, weil sie dann jedes mal x GB downloaden
> muessen.

Öhmm, Spiele mit mehreren GB Programmcode?
Bin kein Spieler, aber das schockt mich dann doch etwas.

: Bearbeitet durch User
von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Andreas B. schrieb:
> Leider nicht, das müßte man sich selbst zurechtbasteln.

Also mehr so Win98-Style-GUI's... Bei Gtk+ (C), GTKmm & Qt (C++), Swing 
& JavaFX (Java), gibt's das schon lange und ist m.M.n. für moderne 
Programme längst Pflicht. Ein Programm mit fixem Fenster-Layout würde 
ich niemandem zumuten...

Andreas B. schrieb:
> Aber ich habe
> auch noch keine Programme gesehen, die das beherrschen.
Nahezu alle GNOME-Fenster (Gtk+) können das, und natürlich alle großen 
Anwendungen wie Firefox, Libreoffice, Word, viele Websites. z.B. der 
Gtk+-WYSIWYG-Designer "Glade" kann solche GUI's auch erstellen.

von Andreas B. (bitverdreher)


Angehängte Dateien:

Lesenswert?

Niklas G. schrieb:
> Nahezu alle GNOME-Fenster (Gtk+) können das, und natürlich alle großen
> Anwendungen wie Firefox, Libreoffice, Word, viele Websites. z.B. der
> Gtk+-WYSIWYG-Designer "Glade" kann solche GUI's auch erstellen.

Ich habe Dich so verstanden, daß sich beim verkleinern der Fenster auch 
die Schriften anpassen. Das macht auch Gnome nicht.
Wenn Du aber meintest, daß sich die Elemente in der Größe anpassen, dann 
geht das auch mit Lazarus/Pascal.

Edit: Hier mal ein Bild dazu, damit man die möglichen Einstellungen für 
ein Element sieht.

: Bearbeitet durch User
von Robert L. (lrlr)


Lesenswert?

pascal vs. c
in am µC Forum, ist immer unterhaltsam

aber um OT zu bleiben:

sch.. da gibts a eigenen Wiki
https://en.wikipedia.org/wiki/DLL_Hell

samt Auswüchsen wie:
https://en.wikipedia.org/wiki/Side-by-side_assembly

von Vn N. (wefwef_s)


Lesenswert?

c-hater schrieb:
> Sprich: du schreibst nur sehr trivialen Code...
>
> [.. sehr viel Scheiß...] meint nämlich: sehr viel Scheiß. D.h.: sehr
> viele Zeilen. Wenn du bei deiner verschissenen schliessenden Klammer
> bist, siehst du die öffnende nicht mehr, d.h.: das Highlighting von
> Klammerpaaren, was natürlich jeder moderene Editor beherrscht, nützt dir
> soviel wie garnix...

Wer professionell Code schreibt, sieht zu, dass seine Funktionen nicht 
1000 Zeilen lang werden und 60 Einrückungen hat, abgesehen ist jeder mit 
einem IQ > Bratwurst fähig, vernünftig eingrückten Code zu lesen. Dein 
"verschissen" kannst du dir behalten, du Simpel.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Andreas B. schrieb:
> Ich habe Dich so verstanden, daß sich beim verkleinern der Fenster auch
> die Schriften anpassen.

Achso, ne das wäre eh nicht sonderlich sinnvoll. Die Schrift sollte sich 
nur grundsätzlich extern setzen lassen, damit man die auf 
hochauflösenden Bildschirmen größer machen kann, ohne das ganze Fenster 
skalieren zu müssen was unschön ist.

Andreas B. schrieb:
> Wenn Du aber meintest, daß sich die Elemente in der Größe anpassen, dann
> geht das auch mit Lazarus/Pascal.

Na dann ist's ja gut...

von Christopher C. (trihexagon)


Lesenswert?

Andreas B. schrieb:
> Niklas G. schrieb:
>> Nahezu alle GNOME-Fenster (Gtk+) können das, und natürlich alle großen
>> Anwendungen wie Firefox, Libreoffice, Word, viele Websites. z.B. der
>> Gtk+-WYSIWYG-Designer "Glade" kann solche GUI's auch erstellen.
>
> Ich habe Dich so verstanden, daß sich beim verkleinern der Fenster auch
> die Schriften anpassen. Das macht auch Gnome nicht.
> Wenn Du aber meintest, daß sich die Elemente in der Größe anpassen, dann
> geht das auch mit Lazarus/Pascal.

Es geht darum, dass man Steuerelemente in andere Steuerelemente 
platziert und diese sich dann nach dem übergeordneten Steuerelement 
ausrichtet. Das ganze ist dann eine Baumstruktur. So kann man GUIs 
bauen, die sich fast beliebig skalieren lassen. Ich nenn das immer 
containerbasierte GUI, einen schönen Sachbegriff hab ich leider noch 
nicht gehört.

Neben solch einer Funktionsweise, zeichnen sich moderne GUI Frameworks 
dadurch aus, dass klar zwischen Logik und Präsentation getrennt wird. 
Die Logik wird weiterhin vom Softwareentwickler in seiner gewohnten 
Umgebung geschrieben. Aber die Präsentation, also wie sehen die 
Steuerelemente aus und wie sind sie platziert, wird vom entsprechenden 
Designer festgelegt (kann natürlich auch ein Softwareentwickler sein). 
Der Designer hat dann seine eigene "Entwicklungsumgebung" und glotzt 
nicht auf irgendein Programmcode, sondern auf eine Beschreibung in XML 
oder Ähnliches wie XAML, QML. Der grafische Designer generiert natürlich 
auch, das XML etc., aber zum Teil ist es wirklich einfacher, präziser 
das selbst einzugeben.

Auch wichtig ist, der korrekte Umgang mit DPI, damit eine Oberfläche auf 
verschiedenen Displays gut aussieht. Die normalen Monitore haben ja noch 
relativ wenig DPI, aber Smartphones, Tablets oder auch 4K Displays haben 
ziemlich viel. Wenn das Framework hier noch altmodisch mit Pixelgrößen 
hantiert, geht das total schief und die GUI ist auf 4K plötzlich winzig.

Ich hab lang nicht mehr Lazarus ausprobiert, aber ich kann mich nicht 
daran erinnern, dass diese angesprochenen Aspekte modern umgesetzt 
waren. Hat sich das geändert? Das heißt natürlich nicht, dass man damit 
keine vernünftigen GUIs hinkriegt. Aber warum sollte ich dann Lazarus 
nehmen, wenn ich auch so moderne/ausgereifte/mächtige GUI Frameworks wie 
WPF, Qt etc. verwenden kann, gerade im professionellen Umfeld. Ob ich da 
Pascal, C# oder C++ benutze ist mir da doch schnuppe.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Gelegenheitsprogrammierer schrieb:
> Ab dann kommen, um zur GUI zu gelangen, die Krücken über Skriptsprachen
> ins Spiel oder eben gleich QT, welches sich aber C++ bedient (also
> zusätzlicher Komplexität, zusätzlichen z.T. beträchtlichem Lernaufwand).

Als jemand, der vor Kurzem ein komplexeres Lazarus-Programm mal
versucht hat zu ändern und ansonsten gelegentlich auch mal ein GUI
in Qt verbrochen hat, muss ich dir allerdings konstatieren, dass ich
in der Komplexität bei beiden keinen grundlegenden Unterschied sehe.
Das liegt gewiss nicht an den verwendeten Programmiersprachen, sondern
an der Thematik selbst.

Klar muss man für native Qt auch irgendwie C++ können, aber nicht
wirklich tiefgreifend mit all seinen Details. Da bei Lazarus dann noch
die passende IDE als Vorteil genannt wird, die einem die Programmierung
der GUI erleichtert – die gibt's bei Qt auch.  Obwohl ich ansonsten
eher spezifische IDEs jedweder Coleur meide (Emacs kenne ich seit 25
Jahren ;), für GUI-Programmierung unter Qt ist deren "Creator" durchaus
genauso brauchbar wie das, was die Lazarus-Protagonisten hier für "ihre"
IDE proklamieren.

Einen wesentlichen Vorteil sehe ich an dieser Stelle natürlich für
Lazarus/Freepascal: es ist komplett frei und Opensource.  Für Qt muss
man im kommerziellen Einsatz dagegen bezahlen.

(Jetzt könnte man natürlich noch Java ins Feld führen …)

Übrigens: Scriptsprachen als „Krücke“ abzutun, disqualifiziert dich
als sachlichen Diskutanten.  Ich habe aktiv in Pascal, C, C++ (naja,
ein wenig :), Perl, Tcl, Python und natürlich auch Assembler Code
geschrieben.  Die Scriptsprachen sind in vielerlei Hinsicht dabei die
viel effizientere Alternative im Vergleich zu Compilaten, vor allem,
wenn man den Aufwand für die Erstellung und Pflege der Software mit
in die Betrachtung einbezieht statt der bloßen Erbsenzählerei
irgendeines Benchmarks.

von (prx) A. K. (prx)


Lesenswert?

Jörg W. schrieb:
> Übrigens: Scriptsprachen als „Krücke“ abzutun, disqualifiziert dich
> als sachlichen Diskutanten.

Yep. Programme, die vom Interface oder von Fileoperationen dominiert 
werden, profitieren nicht von Compilern. Dafür ist aber der 
Entwicklungszyklus bei Compilern wesentlich langsamer.

von Andreas B. (bitverdreher)


Lesenswert?

hristopher C. schrieb:
> Hat sich das geändert?

Ich weiß nicht wie es früher war, aber ich sehe bei den entstandenen 
GUIs auch auf einem 4k Bildschirm keine Probleme (entwickelt auf 1k). 
Auf hochauflösenene Bildschirmen wird das einwandfrei dargestellt. Die 
Forms haben ein dpi setting.

Jörg W. schrieb:
> für GUI-Programmierung unter Qt ist deren "Creator" durchaus
> genauso brauchbar wie das, was die Lazarus-Protagonisten hier für "ihre"
> IDE proklamieren.

Kann ich jetzt nicht bestätigen. Ich habe mal etwas damit herumgespielt, 
bevor ich Lazarus ausgetestet habe. Der QT creator kommt da meiner 
Meinung nach nicht dran.

von (prx) A. K. (prx)


Lesenswert?

Apropos Scriptsprachen und Performance: Ich hatte vor recht langer Zeit 
mal eine ordentliche Menge Textdaten in ein assoziatives Array 
einsortiert (und darauf basierend verarbeitet). Das bildete die Basis 
eines kleinen Laufzeit-Tests. Am schnellsten war Perl, gefolgt von einer 
Classlib von VisualAge Smalltalk. Deutlich abgeschlagen folgte dann eine 
Classlib von VisualAge C++. Also Scriptsprache vorne, JIT-Compiler 
dahinter, C++ Binärcode Schlusslicht.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Andreas B. schrieb:
> Jörg W. schrieb:
>> für GUI-Programmierung unter Qt ist deren "Creator" durchaus
>> genauso brauchbar wie das, was die Lazarus-Protagonisten hier für "ihre"
>> IDE proklamieren.
>
> Kann ich jetzt nicht bestätigen. Ich habe mal etwas damit herumgespielt,
> bevor ich Lazarus ausgetestet habe. Der QT creator kommt da meiner
> Meinung nach nicht dran.

Gut, dann haben wir hier zwei verschiedene Meinungen. ;-)

GUIs zu entwerfen ist allerdings nicht das, was ich hauptsächlich
als Software produziere, insofern habe ich bei beiden wohl eine größere
Lernkurve als bei anderen Dingen.  Am einfachsten fand ich den GUI-Kram
übrigens (wie Chris) tatsächlich bei Tcl/Tk, auch wenn ich die Syntax
von Tcl nicht unbedingt so sehr mag.  (Tk in anderen Sprachen wie Python
oder Perl ist aber kaum handlicher.)

von Keiner N. (nichtgast)


Lesenswert?

Da der halbe Thread OT ist :)

wie sieht es denn bei Delphi/Lazarus und co eigentlich mit eigenen 
Steuerelementen aus?

Ich mache viel mit C#/WPF und da kann man sich ja wunderbar alles 
mögliche sehr einfach zusammenschrauben. Damit meine ich nicht nur einen 
Button mit nem Bild drauf, sondern auch TreeNodes mit Icon, Checkbox, 
Combobox und im Hintergrund läuft noch eine Progressbar mit.

Ist das eher einfach oder eher kompliziert?


PS: Das ist eine ernstgemeinte Frage und keine Trollfrage.

von G. P. (gelegenheitsprogramm)


Lesenswert?

Jörg W. schrieb:
> Übrigens: Scriptsprachen als „Krücke“ abzutun, disqualifiziert dich
> als sachlichen Diskutanten.

Hallo Jörg, das war von mir gar nicht abfällig gemeint (es hätte es in 
Anführung schreiben sollen). "Krücke" um zur GUI zu gelangen meinte ich 
hier als Hilfsmittel, das es wie z.B. im Fall von Lazarus oder C#/.NET 
(sind nur Beispiele) so nicht braucht. Zumindest nicht, um ein GUI 
Programm zu erstellen. Zumal die Hinzunahme von Python oder TCL ja 
wiederum zusätzliche Komplexität hinzufügt, d.h. man muss sich auch dort 
wieder langwierig hineinfinden. Das mag für Leute, die sowieso jeden Tag 
acht oder mehr Stunden coden (und das vielleicht seit Jahren) ein müdes 
bemitleidenswertes Lächeln hervorrufen, aber für jemanden, der in 
unregelmäßigen Abständen mal was programmiert (sei es weil er es braucht 
oder sei es aus reinem Interesse) spielt das halt alles eine Rolle.

Also bitte nicht böse sein, es war nicht abfällig gemeint.

;)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

G. P. schrieb:
> Zumindest nicht, um ein GUI Programm zu erstellen.

Kann man so sehen, muss man nicht.

Die GUI-Funktionalität ist ja oft ohnehin gut vom Rest abtrennbar.

Nichtsdestotrotz benutzen wir gerade im professionellen Umfeld mehr
und mehr Python, insbesondere in der Evaluierungsphase.  Ist nicht
unbedingt meine Lieblingssprache, aber man arrangiert sich damit, und
insbesondere numerische Mathematik (die wir sehr viel benutzen)
integriert sich gut.  Dass dann, wenn man dazu ein GUI braucht, dieses
auch gleich mit in Python gezimmert wird, liegt nahe.

Portierung nach C (für den Controller) kommt dann erst später, wenn
die Algorithmen stehen.  Über Pascal redet an dieser Stelle niemand,
weder wir noch unsere Kunden.  Gründe für Nichtverwendung von Pascal
im Controllerbereich wurden ja oben schon genannt.  Obige Analyse war
zwar für AVR, wir benutzen ARM, aber ich fürchte, dass das Ergebnis
sich kaum substanziell unterscheiden dürfte.  (Als Entwickler würden
wir auch lieber C++ statt C nehmen, hat aber bislang noch nicht
gepasst.  Ein großes Projekt stellt man nicht einfach mal so auf was
anderes um, denn kein ${KUNDE} würde einem das bezahlen wollen.)

von G. P. (gelegenheitsprogramm)


Lesenswert?

Jörg W. schrieb:
> Am einfachsten fand ich den GUI-Kram
> übrigens (wie Chris) tatsächlich bei Tcl/Tk, auch wenn ich die Syntax
> von Tcl nicht unbedingt so sehr mag.

Das ist für mich (andere mögen es anders sehen) eher ein Widerspruch der 
nicht zusammengeht. Wenn ich die Syntax schon im Ansatz nicht mag 
verliere ich automatisch die Lust mich damit tiefer zu befassen und 
solange es Alternativen gibt ..

;)

von Andreas B. (bitverdreher)


Angehängte Dateien:

Lesenswert?

Keiner N. schrieb:
> sich ja wunderbar alles
> mögliche sehr einfach zusammenschrauben. Damit meine ich nicht nur einen
> Button mit nem Bild drauf, sondern auch TreeNodes mit Icon, Checkbox,
> Combobox und im Hintergrund läuft noch eine Progressbar mit.

Du hast Steuerelemte ohne Ende. Auch schon so fertige Dinge wie 
Zeit/Datum auswahl, Fileauswahl, Datenbankelementa und was weiß ich noch 
alles.
Schau Dir einfach mal den Screenshot an. Dort siehst Du unter der 
Kopfzeile die Standardelemente. In jedem Tab finden sich weitere 
Steuerelemente. Da ist alles was das Herz begehrt. Im Netz finden sich 
dann noch mehr, falls das nicht reicht.
Es gibt natürlich auch eine Progressbar, aber was die anzeigen soll, 
mußt Du natürlich selber programmieren. Eine Glaskugel ist leider nicht 
enthalten.
Anklicken und auf der Form aufziehen. Dann mit Leben füllen. Ich wüßte 
nicht wie man das noch einfacher machen sollte.

von G. P. (gelegenheitsprogramm)


Lesenswert?

Chris D. schrieb:
> G. P. schrieb:
>> Na ja, TCL/TK Scheint mir aber auch kein leuchtendes Beispiel für
>> Anfängerfreundlichkeit oder Gelegenheitsbenutzer zu sein:
>>
>> https://wiki.tcl.tk/1048
>>
>>> proc ilist { {begin {.}} {listf {winfo children}} {maxdepth {100}}
>> {ident {0}} } {
>>     if {$maxdepth <1} return
>>     set de {}; set o {}
>>     for {set i 0} {$i < $ident} {incr i} {append de {   }}
>>     foreach i [eval "$listf $begin"] {
>>         append o "$i "
>>         #puts "$de $i"
>>         append o [ilist $i $listf [expr $maxdepth-1] [expr $ident +1]]
>>     }
>>     return $o
>> >
>> Mein Bauchgefühl sagt mir da eher, lass gut sein.
>
> Und wie so oft täuscht das Bauchgefühl :-)
>
> Man kann in jeder Sprache Beispiele konstruieren, die erst einmal
> undurchsichtig erscheinen - und wenn die dann auch noch unglücklich
> formatiert und schlecht gemacht sind, sieht das natürlich wild aus.

Ich hatte bisher noch nicht das Vergnügen irgendwas mit TCL zu machen. 
Das war einfach ein willkürlich herausgegriffenes Beispiel aus dem Wiki 
für TCL.

> Tatsächlich ist die Tcl-Grammatik aber sehr einfach und orthogonal
> aufgebaut. Einfach mal die Anfängertutorien anschauen :-)

Ich glaube da orientiere ich mich erst mal anderweitig ..

> Aber das gehört hier alles nicht her und war nur ein Beispiel dafür,
> dass man auch jenseits des "Mainstreams" glücklich werden kann.

Ja, ich hatte auch das Gefühl (womit wir wieder beim Bauchgefühl wären) 
dass TCL etwas sehr abseitig vom Mainstream ist, zumal wenn man quasi 
selber eigentlich nur noch in Windows unterwegs ist. Sich dann zu sehr 
jenseits des Mainstream zuzuwenden bringt einem früher oder später nach 
meiner Erfahrung (ich bin mit Turbo Pascal sozialisiert worden, später 
zu Turbo C gewechselt) mehr Probleme als wirklichen Nutzen. Für 
Mikrocontroller im Zusammenhang mit Pascal wurde das ja bereits 
angesprochen. Hier ist man mit C einfach breiter aufgestellt.

von Chris D. (myfairtux) (Moderator) Benutzerseite


Lesenswert?

G. P. schrieb:
> Ich hatte bisher noch nicht das Vergnügen irgendwas mit TCL zu machen.
> Das war einfach ein willkürlich herausgegriffenes Beispiel aus dem Wiki
> für TCL.
>
>> Tatsächlich ist die Tcl-Grammatik aber sehr einfach und orthogonal
>> aufgebaut. Einfach mal die Anfängertutorien anschauen :-)
>
> Ich glaube da orientiere ich mich erst mal anderweitig ..

Das ist jedem freigestellt - man hat ja auch eine riesige Auswahl :-)

Allerdings: die Kombi Tcl/Tk ist gerade für Leute, die nur ab und zu mal 
etwas machen, sehr gut geeignet - weil so einfach aufgebaut.
Und gerade für Anfänger deutlich besser geeignet als Qt, GTk usw.

> Sich dann zu sehr
> jenseits des Mainstream zuzuwenden bringt einem früher oder später nach
> meiner Erfahrung (ich bin mit Turbo Pascal sozialisiert worden, später
> zu Turbo C gewechselt) mehr Probleme als wirklichen Nutzen.

Ja, mit Turbo Pascal habe ich auch angefangen :-)

Das es nicht Mainstream ist, heisst hier übrigens nicht, dass es nicht 
weiter entwickelt würde. Es gibt für Tcl eine kleine, stabile Gemeinde.

Für mich auch wichtig: Tcl/Tk steht unter einer BSD-Lizenz.

> Mikrocontroller im Zusammenhang mit Pascal wurde das ja bereits
> angesprochen. Hier ist man mit C einfach breiter aufgestellt.

Ja, man muss da einfach abwägen: ist der Gewinn, den ich erhalte, es 
wert, vielleicht noch eine zweite Sprache einzusetzen?

Wir fahren hier bspw. mit bei GUIs auf Controllern (selbst AVRs) mit 
einem eingebauten Tcl/Tk-Interpreter sehr gut. Es gibt hier tatsächlich 
Steuerungen, die laufen ausschließlich nativ unter Tcl (mit natürlich 
der selbstgeschriebenen Hardwareschnittstelle).

Ist alles eine Frage der Anforderungen, Vorlieben und natürlich der 
Vorbildung :-)

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

A. K. schrieb:
> Classlib von VisualAge C++

Was ist denn eine "Classlib" im C++-Kontext? Das VisualAge C++ schon 
längst eingestellt ist spricht nicht für dessen Qualität. C++ bietet 
selbst mit "map" einen assoziativen Container.
Hier das Performance-Gegenbeispiel:
https://github.com/Erlkoenig90/langcomp
Hat jemand Lust das um Pascal zu erweitern? :)

von Robert L. (lrlr)


Lesenswert?

Keiner N. schrieb:
> Ich mache viel mit C#/WPF und da kann man sich ja wunderbar alles
> mögliche sehr einfach zusammenschrauben. Damit meine ich nicht nur einen
> Button mit nem Bild drauf, sondern auch TreeNodes mit Icon, Checkbox,
> Combobox und im Hintergrund läuft noch eine Progressbar mit.

kann man selber machen, .. also eigene Controls und Components
das haben aber natürlich schon andere gemacht:

siehe z.B: VirtualTreeView, JVCL, Indy, usw.
(alle 3 übrigens extrem mächtig, sollte man sich angeschaut haben..)

man kann auch ganze Fenster "vererben", oder gewisse Teile 
wiederverwenden (Frames)


Delphi ist/war aber immer schon eher richtunge RAD+Datenbank angesiedelt

inzwischen mit (visual) data-binding für jedes x-beliebige eingabefeld.. 
usw.


Delphi (allerdings ohne VCL) wäre inzwischen plattformübergreifend, samt 
Iphone, Android, IOS und was weiß der Geier..

von (prx) A. K. (prx)


Lesenswert?

Niklas G. schrieb:
> Hier das Performance-Gegenbeispiel:

Das war eine punktuelle Sache, natürlich nicht repräsentativ. Ich wollte 
damit nur ausdrücken, dass die Sache nicht so eindeutig sein muss, wie 
man gerne annimmt.

Ein Gegenbeispiel habe ich auch. REXX war nämlich auch dabei.

: Bearbeitet durch User
von Johnny B. (johnnyb)


Lesenswert?

Delphi war früher super und ich habe es selbst sehr viel benutzt in 
Zeiten wo die "Visuellen" Entwicklungsumgebungen von Visual Basic und 
C/C++ noch in den Kinderschuhen steckten.
Aber seit sich Visual Studio derart gemausert hat und technisch immer 
auf dem neusten Stand gehalten wird, nutze ich für die PC Programmierung 
(Windows) vorwiegend dieses.
Ausserdem ist es halt noch sehr interessant, da die kleinen Versionen 
von Visual Studio schon seit vielen Jahren kostenlos sind, sogar für die 
kommerzielle Nutzung.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Johnny B. schrieb:
> Ausserdem ist es halt noch sehr interessant, da die kleinen Versionen
> von Visual Studio schon seit vielen Jahren kostenlos sind, sogar für die
> kommerzielle Nutzung.

Das wäre dann wohl allerdings eher ein Argument für Lazarus (und damit
Freepascal) …

von Holm T. (Gast)


Lesenswert?

Yalu X. schrieb:
[..]
>
> 4. Kartenspiel: Selbst nach fünf Bier weiß ein Skatspieler, dass er
>    besser kein Pik-Spiel ansagen sollte, wenn er auf keiner seiner
>    Karten ein ♠ sieht.
[..]

Laß das mal außen vor, Deine Erklärungen zu Sprachen sind interessant, 
aber von Skat verstehst Du nichts,

Gruß,

Holm

von Holm T. (Gast)


Lesenswert?

c-hater schrieb:
> Bernd K. schrieb:
>
>> Ich weiß nicht was ihr so treibt aber ich rücke vernünftig ein (bzw. die
>> IDE macht das fast von selbst) und da sehe ich sofort welches end zu
>> welchem begin gehört.
>
> Sprich: du schreibst nur sehr trivialen Code...
>
> [.. sehr viel Scheiß...] meint nämlich: sehr viel Scheiß. D.h.: sehr
> viele Zeilen. Wenn du bei deiner verschissenen schliessenden Klammer
> bist, siehst du die öffnende nicht mehr, d.h.: das Highlighting von
> Klammerpaaren, was natürlich jeder moderene Editor beherrscht, nützt dir
> soviel wie garnix...

Dafür gibts im Editor das '%' Zeichen..

Gruß,

Holm

von S. B. (Gast)


Lesenswert?

> Wie kommt es, das von vielen Pascal/Lazarus/Delphi oft als
> Anfängersprache bezeichnet wird?
weil Pascal in der Historie zeitlich früher am Markt war, C kam erst 
circa 2 Jahre später auf.

> Tatsächlich hat sich Pascal genauso wie C und C++ seit damals
> weiterentwickelt.
bleib doch dabei - es gibt auch Basic Neuerungen; letztendlich kommt es 
auf die Anwendung/fertiges Programm an.

> Immer wird darüber geredet, das C++ das auch könnte..nur ständig wenn
> ich ein in C++ geschriebenes Programm Installieren!!
C++ hat sich u.a. wegen der einfacheren GUI Programmierung durchgesetzt, 
das geht in C nur mit GTK+ und ist komplizierter.
Nicht nur die Updates sind aufwendiger bei C++, auch der ganze Quellcode 
ist wesentlich aufgeblähter (bei C nicht) - was wegen Speicher und 
schneller Rechner aber keinerlei Rolle mehr spielt, deswegen hat sich 
C++ damals durchgesetzt.
Heute ist wegen Platformunabhängigkeit eher Java angesagt.
Aber ich würde an Deiner Stelle bei dem bleiben was mir gefällt; C++ ist 
für mich eine Fehlentwicklung, die sich nur wegen Klickibunti-Icons 
durchgesetzt hat.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

S. B. schrieb:
> Nicht nur die Updates sind aufwendiger bei C++, auch der ganze Quellcode
> ist wesentlich aufgeblähter (bei C nicht)

Letzteres kannst du so nicht stehen lassen.  Beispiele, bei denen
das gleiche Problem in C++ eleganter lösbar ist als in C findest du
zuhauf, und spätestens bei GUIs dreht sich die Aussage sowieso 'rum.

Aber das würde nun endgültig den Rahmen dieses Threads sprengen und
ist anderweitig hier im Forum schon zur Genüge durchgekaut worden.
Bitte also nicht auch noch hier.

von Johnny B. (johnnyb)


Lesenswert?

Jörg W. schrieb:
> Letzteres kannst du so nicht stehen lassen.  Beispiele, bei denen
> das gleiche Problem in C++ eleganter lösbar ist als in C findest du
> zuhauf

C hat schon viele Schwächen.
Einige tolle Verbesserungen gibt's in Holy C, aber das ist nicht so sehr 
verbreitet.
Interessant im Video zu sehen ist wie dort mit Strings umgegangen wird 
und Erweiterungen von Switch/case.
https://www.youtube.com/watch?v=7uLzaKlZSQQ

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Johnny B. schrieb:
> C hat schon viele Schwächen.

Bestreitet gewiss keiner …

von (prx) A. K. (prx)


Lesenswert?

S. B. schrieb:
>> Wie kommt es, das von vielen Pascal/Lazarus/Delphi oft als
>> Anfängersprache bezeichnet wird?
> weil Pascal in der Historie zeitlich früher am Markt war, C kam erst
> circa 2 Jahre später auf.

Und auch auf völlig anderen Plattformen. Pascal kam zuerst für die 
CDC6600 - grösser ging damals kaum. Und C kam im Gefolge von Unix für 
die PDP-11, was ungefähr die kleinste Plattform war, auf die man ein 
brauchbares Betriebssystem kriegte.

Das ging auch zunächst so weiter. Pascal verbreitete sich auf andere 
Mainframes, C auf Minicomputer. Lehrsysteme für Anfänger waren bis in 
die 80er aber die grossen Systeme, nicht die kleinen.

: Bearbeitet durch User
von KArl Fred M. (Gast)


Lesenswert?

Das scheint sich momentan etwas zu ändern:-)
https://www.tiobe.com/tiobe-index/

von Norbert S. (norbert_s224)


Lesenswert?

Insbesondere FreePascal hat sich in den letzten Jahren weiterentwickelt. 
Die "Anfängersprache" ist zu einer guten, leistungsfähigen und soliden 
objektorientierten Sprache herangewachsen.
Da in der Zwischenzeit an den Schulen dank des Java-Hypes aber nur mehr 
diese Sprache gelert wird, verschwindet auch der Nachwuchs der mit 
dieser Programmiersprache in Kontakt kommt.
Über die Vor- und Nachteile von Java kann man an anderer Stelle 
diskutieren, aber dort wo es schnellen Code benötigt, ist ein nativer 
Compiler einfach unschlagbar.
Ich selbst hab jahrelang professionelle Software mit Delphi entwickelt 
und kam nach bitter bereuten Ausflügen nach C/C++ immer wieder gerne auf 
Delphi zurück.
Und nun hab ich seit gut 10 Jahren Maschinenvisualierungen, die mit 
FreePascal programmiert wurden und DirectX nützen, am laufen.
Die Entscheidung auf FreePascal zu setzen hab ich keinen Tag bereut.
Wie ich mal in einem Forum gelesen habe: Pascaler benötigen keinen 
Garbage-Collector, sie produzieren keinen Müll ;)

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.