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
ä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
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?
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 :-(
ach ja...das Gleiche gilt natürlicha uch für Basic. Auch das erlaubt direkten Hardwarezugriff meines Wissens nach..
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.
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?
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.
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.
Die Programmierspache von der Stange für uC ist halt mal C, nicht Pascal.
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.
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
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.
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
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.
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‘
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.
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. ;)
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.
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.
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.
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.
Sag mal wieso antwortest du nicht im Originalthread, ist das zu kompliziert für Pascalnutzer?
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
Webfehler schrieb:
[..]
lt. DUDEN:
Webfehler, 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
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?!
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.
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.
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
Yalu X. schrieb: > - eine Implementierung der Eigen-Bibliothek Das nutzt doch komplexe Techniken der Metaprogrammierung (Expression templates...). Geht das in Pascal?
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.
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?
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
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.
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
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.
Angehängte Dateien:
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
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
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.
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...
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.
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.
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.
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.
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
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.)
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.
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. ;)
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.)
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 .. ;)
Angehängte Dateien:
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.
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.
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 :-)
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? :)
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..
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
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.
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) …
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
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
> 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.
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.
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
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
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 ;)
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.