Wie kommt es, das von vielen Pascal/Lazarus/Delphi oft als Anfängersprache bezeichnet wird? Tatsächlich hat sich Pascal genauso wie C und C++ seit damals weiterentwickelt. Liegt es daran, das viele, als es Borland damals mit Pascal für Windows vermasselt hatte, auf C umgestiegen sind, und gar nicht gemerkt haben, das der Fehler von Borland von anderen ausgemerzt wurde, dadurch das sich das Sterben von Borland so lange hingezogen hatte? Ich finde nach wie vor, das Lazarus/Deplhi/PAscal unschalgbar für die meisten Anwendungen ist. Und alltägliche Tools wie der Totalcommander, zeigen auch, das solche Tools den der C Fans in nichts nachstehen. Im Gegenteil, lassen sich PAscal Progamme einfachst kopieren, ohne irgendwelche Installationsroutine oder was auch immer. 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! Bei einem PAscal Programm muss NIE irgendwas nachgeladenw erden. Und kleiner ist es meist noch dazu..selbst wenn das C Programm mal kleiner ist..wird das mehr als vermasselt, dadurch das etliche fette MS Updates erforferlich sind..spätestens mit diesen ist das C++ Programm um ein vielfaches größer. In C++ sehe ich eigentlich nur MS Visual C++ als vergleichbar, was das schnelle Erstellen von Programmen angeht Anbei mal eine Liste von Spielen die in Delphi/Lazarus Pascal programmiert wurden https://www.youtube.com/watch?v=aTyYM12YRew https://www.youtube.com/watch?v=-BIJbc-yUkY Wäre schön, wenn es sachlich bleiben könnte! Link zu Lazraus PAscal https://www.lazarus-ide.org/
:
Verschoben durch User
Max S. schrieb: > Wie kommt es, das von vielen Pascal/Lazarus/Delphi oft als > Anfängersprache bezeichnet wird? Ist das so? Ich habe Lazarus erst vor einem Jahr "entdeckt" und es ist jetzt meine Stadardprogrammiersprache für den PC unter Linux. Die Programme lassen sich 1:1 für Windows übersetzen.
Das mit dem "Nachinstallieren" scheint am Linken zu liegen: Während du in C alle Libryries dynamisch linken kannst (und somit Windows Librariex etc. bzw. bestimmter Frameworks verwendet werden) scheint Delphi alles statisch zu linken. Das geht natürlich auch in C/C++. Und natürlich ist es vorteilhaft, dass Delphi sein eigenes GUI Framework mitbringt und es nicht 1000 Deriviate von MFC bis QT gibt. Daher ist das unter Win und Linux compilierbar. Ich selbst bin am liebsten unter C/C++, STL und Templates sowie mit Pointern unterwegs. GUI, große Datenmengen schnell verarbeiten und konvertieren, graphisch ausgeben, Compile-tools entwickeln etc. :-) Auf dem µC dann mit C und Compiler Intrinsics.
:
Bearbeitet durch User
Max S. schrieb: > Wie kommt es, das von vielen Pascal/Lazarus/Delphi oft als > Anfängersprache bezeichnet wird? Weil Pascal vor dem Java-Hype gerne als solche verwendet wurde. > Im Gegenteil, lassen sich PAscal Progamme einfachst kopieren, ohne > irgendwelche Installationsroutine oder was auch immer. Das hat nichts mit der verwendeten Programmiersprache zu tun. > 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! Weil der Entwickler Visual C++ mit dynamisch gelinkter Runtime-Library verwendet hat, die muss dann natürlich vorhanden sein. > Bei einem PAscal Programm muss NIE irgendwas nachgeladenw erden. Weil Du es statisch linkst oder nur auf dem System testest, wo die IDE mitsamt aller Runtime-Libraries installiert ist? > In C++ sehe ich eigentlich nur MS Visual C++ als vergleichbar, was das > schnelle Erstellen von Programmen angeht Geht es gerade um Programmiersprachen oder um "RAD"?
Es geht um Pascal im Allgemeinen, das schließt RAD etc mit ein...
Hmmm schrieb: > Weil Du es statisch linkst oder nur auf dem System testest, wo die IDE > mitsamt aller Runtime-Libraries installiert ist? Wie das genau geht weiß ich nicht, kann aber bestätigen dass eine mit Lazarus & Standardeinstellungen erstellte .exe auf jedem Windows System läuft.
>Wie das genau geht weiß ich nicht,
Das ist doch ein alter Hut. Seit es Delphi gibt, damals noch für Windows
3.11, wurden sämtliche Libraries, die man für Windows braucht, speziell
die Unit "Forms", immer komplett in die kompilierte *.exe eingebaut
(sofern man kein reines Konsolen-Programm gebaut hat). Deshalb braucht
man bei Delphi- und -Lazarus Programmen normalerweise nur die
*.exe-Datei und sonst nichts, was bei manchen C++-Programmierern
seinerzeit für ungläubiges Staunen gesorgt hat.
Als Nachteil war die *.exe natürlich sehr viel größer als vergleichbare
C++-Programme, weil da eben schon alle Funktionen drin sind, die man bei
C++-Programmen in externe DLLs ausgelagert hat oder noch separat dazu
installieren musste.
Max S. schrieb: > Wie kommt es, das von vielen Pascal/Lazarus/Delphi oft als > Anfängersprache bezeichnet wird? Weil Pascal von Niklaus Wirth genau für diesen Zweck, nämlich als Lehrsprache entwickelt wurde. Lehrsprache und Anfänger passt doch erstmal zusammen C mit seinen vielen Freiheiten lässt den gerade Anfänger mit seinen Compiler Fehlermeldungen oft im Regen stehen, wo Pascal auf Grund der Sprachkonstuktion für den Anfänger viel spezifischer sein kann.
eben,, es WAR dafür konzipiert..ist es aber schon ewig nicht mehr. Irgendwie hat sich das genauso festgesetzt, wie das Batterien immer ganz leer gemacht werden sollen, bevor man sie wieder auflädt...was auch schon seit 20 Jahren nicht mehr stimmt aber immer noch in den Köpfen der Menschen steckt aus den alten Nickel Cadmium Zeiten..
Da die ISO-Norm seit ein paar Jahrzehnten keine Neuerung erfahren hat (und Pascal wohl kaum eine perfekte Sprache ist), mutmaße ich, dass man heutzutage entweder auf altem Sprachniveau arbeitet, oder seinen Code von einer Implementation abhängig macht. Ist das richtig oder sehe ich das vollkommen falsch? Haben sich andere Sprachstandards etabliert?
Max S. schrieb: > Ich finde nach wie vor, das Lazarus/Deplhi/PAscal unschalgbar für die > meisten Anwendungen ist. Es geht auch oft garnicht um die Sprache an sich, sondern um das Verhalten von Embarcadero. Beispiel bei mir: ich habe schon Heimsoeth Turbo Pascal verwendet und kenne mich in Pascal schon ziemlich perfekt aus, und ich habe bis Delphi 7 alles ordnungsgemäss upgedatet - das Update von Delphi 7 auf 8 habe ich dann zwar bezahlt, war nicht wirklich billig, aber dann hat mir der Server von Embaracadero mitgeteilt, meine Software wäre schon woanders registriert, und hat mich ausgesperrt. Selbstverständlich habe ich keinen Cent zurückbekommen, Embarcadero sagt einfach, das ginge sie garnichts an, ich müsste halt einfach ganz neu kaufen. Wenn man die Politik betreibt, Altkunden als Altlast abzuschütteln, ist das Ergebnis natürlich ein schwindender Kundenstamm. Mir blieb ja auch nichts anderes übrig, als alte Programme weiter mit Delphi 7 zu pflegen und mit Delphi nichts neues mehr anzufangen. Ich bin da ganz sicher kein Einzelfall. Ursprünglich tat mir das leid, aber inzwischen ist mir klar dass es keinen Sinn hat ein totes Pferd nur aus Gewohnheit weiterzureiten. Damit erübrigt es sich auch über Vor- und Nachteile zu diskutieren. Delphi/RAD ist ja keine Billigversion, da ist die Zumutung, öfter mal neu kaufen zu müssen völlig unzumutbar. Georg
Zu meiner c/c++ Zeit war eher das Problem eine brauchbare bzw. funktionierende Entwicklungsumgebung zu finden die vor allem auch 3D-Grafik konnte. Man glaubt gar nicht was für Probleme es geben kann bis der Compiler läuft.
das ist auch so eine Saceh die ich bei den freien C Projekten nicht verstehe.. Lazarus nutzt Freepascal als Basis, nur merkt man davon nichts, da es voll integriert ist. Wieso bekommen die Leute es aus der C Fraktion nicht gebacken, eine komplett zusammengestellte Version auf die Beine zu stellen. Es ist der gleiche Zirkus wie bei Linux mit bescheuerten Argumenten wie..man soll ja die freie Wahl haben blaaaa Hätte man ja dennoch, auch wenn es einfach eine montierte und eine zerfledderte Version gäbe. Freepascal gibt es ja auch noch eigenständig , es gibt sogar bereits alternativen zu Lazarus..dennoch ist nicht alles zerstückelt..sondern man lädt es runter..installiert..startet..läuft...ALLES, bis auch die Hilfen..warum die das nicht integrieren verstehe ich nicht--- Aber bei C wirkt alles nur wie Gefrickel..als ob die verschiedenen Projekte nicht in der LAge sind miteinander zu arbeiten oder sich zu koordinieren oder was auch immer
Ich habe letztes Jahr mal versucht was in Lazarus zu machen, es hat nicht geklappt. Vielleicht gehe ich da als Lazarus Anfänger falsch ran, aber die GUI ist ein paar mal abgestürzt. Auch waren die Widgets jetzt nicht so dass ich sooo grosse Vorteil hätte (Graphen zur Darstellung von wissenschaftlichen Daten habe ich nicht gefunden) Es hat (leider) keinen so guten Eindruck gemacht.
abgestürzt?!?! Okayyyyy..ist bei mir noch nie passiert.. Vielleicht können die anderen was dazu sagen
hast Du das mal ins Lazarus Forum geschrieben? Normalerweise kümmert sich da immer jemand fix drum
Max S. schrieb: > Ich finde nach wie vor, das Lazarus/Deplhi/PAscal unschalgbar für die > meisten Anwendungen ist. Ich finde es ist ein verbuggter Müllhaufen. Freepascal geht vielleicht noch aber die ganzen schlecht rangeflanschten libs in Lazarus sind doch ein elendiges Gebastel. Ich habe damit mal ein paar GUIs versucht zu bauen, da kam nur instabiler Müll bei raus, fast so wie das Original Delphi von Borland, das war ja auch in einige Versionen völlig kaputt, da hatten die Lazarus irgendwie das Original an der flaschen Stelle zu exakt nachgebildet. Die barocke Sprachbasis nervt doch heute nur noch, in den 70ern war das vielleicht ein Fortschritt und als imperative Lehrsprache ideal aber sowas will ich nicht verwenden müssen um damit täglich zu entwickeln.
Stefan BT. schrieb: > Wieso bekommen die Leute es aus der C Fraktion nicht gebacken, eine > komplett zusammengestellte Version auf die Beine zu stellen. Codeblocks, Dev-C++
klingen beide auch nicht super :-( http://www.cplusplus.com/forum/windows/214068/ Probleme gibt es wohl bei allem egal ob C oder Pascal Compilern Aber egal, wir sind ja bei Pascal ;-)
dumdidum (nicht angemeldet) schrieb: > Ich habe letztes Jahr mal versucht was in Lazarus zu machen, es hat > nicht geklappt. bei mir dito vor ca. 3 Jahren, Lazarus ist zwar nicht abgestürzt, es hat aber irgendwas gefehlt, weiß schon gar nicht mehr was. Also schon mal nichts mit einfach kopieren und los gehts. Im Lazarusforum waren sie zwar deutlich netter als hier, aber außer alles löschen und neuinstallieren ist ihnen auch nichts eingefallen.
Walter schrieb: > Im Lazarusforum waren sie zwar deutlich netter als hier, aber außer > alles löschen und neuinstallieren ist ihnen auch nichts eingefallen. Was nützt nett wenns dann inkompetent ist. Dann lieber einen (echten) MaWin. Du wirst vieleicht angeschissen aber bekommt zu 95% eine gute Lösung/Hinweis
Der Andere schrieb: > Was nützt nett wenns dann inkompetent ist. Bisher hab ich auf alle Fragen im Lazarus / FPC Forum brauchbare Antworten bekommen, die zu einer Problemlösung führten. dumdidum (nicht angemeldet) schrieb: > Graphen zur Darstellung von > wissenschaftlichen Daten habe ich nicht gefunden TChart. Kannst Du direkt mit einbauen, genauso wie Datenbanken. Entweder ist das schon seeehr lange her oder Du hast nur mal kurz drübergeschaut. georg schrieb: > Mir blieb ja auch > nichts anderes übrig, als alte Programme weiter mit Delphi 7 zu pflegen > und mit Delphi nichts neues mehr anzufangen. Das kenn ich. Ich muss auch noch das alte StarOffice nehmen, was nicht mehr weiterentwickelt wird. Ich bin absolut nicht in der Lage, stattdessen OpenOffice oder gar LibreOffice zu nehmen. Es geht einfach nicht. Man, FreePascal, man. Das hat einen Delphi Importer und für ganz Harte kann man es wohl auch auf Delphi-Like umstellen. Random .. schrieb: > sowie mit > Pointern unterwegs Du musst jetzt sehr tapfer sein: copy_string(@text, @dispbuffer); Ja, FreePascal kann auch Pointer.
Max S. schrieb: > Wie kommt es, das von vielen Pascal/Lazarus/Delphi oft als > Anfängersprache bezeichnet wird? Ich sehe das ähnlich wie Wolfgang: Wolfgang schrieb: > Weil Pascal von Niklaus Wirth genau für diesen Zweck, nämlich als > Lehrsprache entwickelt wurde. > Lehrsprache und Anfänger passt doch erstmal zusammen Es gibt IMHO einen kleinen Unterschied zwischen einer Anfänger- und einer Lehrsprache: Eine Anfängersprache soll, egal wie, einen möglichst raschen Einstieg in die Programmierung ermöglichen. Ein Beispiel ist das klassische BASIC. Eine Lehrsprache soll Grundlagen der Programmierung vermitteln. Gründlichkeit, systematische Vorgehensweise und guter Programmierstil sind dabei wichtiger als der schnelle Erfolgserlebnis. Genau dafür wurde Pascal ursprünglich entwickelt. > Tatsächlich hat sich Pascal genauso wie C und C++ seit damals > weiterentwickelt. ... nur sehr viel langsamer. Obwohl Pascal 1 bis 2 Jahre vor C gestartet ist, waren die meisten Neuerungen in C bzw. C++ deutlich früher verfügbar als in Pascal bzw. Object Pascal. Als ich hobbymäßig und später im Studium Pascal lernte, waren die zur Verfügung stehenden Pascal-Dialekte noch voller Restriktionen, was ich zunächst einfach so hinnahm. Erst als mit C anfing, merkte ich, dass es auch anders geht. Damit war Pascal für mich erst einmal gestorben. Als ich dann das erste Mal mit Turbo-Pascal in Kontakt kam (es war eine Vorgabe in einem Entwicklungsauftrag), sah ich, dass darin die o.g. Restriktionen auf ein gesundes Maß reduziert waren. Zu diesem Zeitpunkt konnte ich C aber schon so gut, dass ich nach Abschluss des Projekts mich weiterhin C zuwandte. Als dann OOP groß in Mode kam, fing ich als logische Fortsetzung von C mit C++ an. Während C++ zu diesem Zeitpunkt schon einige Jahre gereift war, stand Turbo-Pascal mit seinen OOP-Erweiterungen noch ganz am Anfang. Zudem konnte ich C++ im Gegensatz zu Turbo-Pascal auch beruflich nutzen, so dass für Turbo-Pascal und seine Nachfolger bestenfalls noch der Hobbybereich blieb. Fürs Hobby, wo für mich einzig und alleine der Spaßfaktor zählt, gibt es unter den Unmenge von Programmiersprachen aber deutlich interessantere Alternativen.
Vka schrieb: > Wie das genau geht weiß ich nicht, kann aber bestätigen dass eine mit > Lazarus & Standardeinstellungen erstellte .exe auf jedem Windows System > läuft. Stimmt nicht ganz. Alles, was bei Lazarus an librarys nicht dabei ist und nachinstalliert wurde, muß auch am Zielrechner als Dll mitgeliefert werden. Wolfgang schrieb: > Weil Pascal von Niklaus Wirth genau für diesen Zweck, nämlich als > Lehrsprache entwickelt wurde. Das verwendete Objectpascal hat mit den ursprünglichen Pascal eigentlich nur noch wenig zu tun. georg schrieb: > Ursprünglich tat mir das leid, aber inzwischen ist mir klar dass es > keinen Sinn hat ein totes Pferd nur aus Gewohnheit weiterzureiten. Du kannst problemlos Lazarus statt Delphi verwenden. Das wird gut gepflegt und kostet auch nichts. dumdidum (nicht angemeldet) schrieb: > Es hat (leider) keinen so guten Eindruck gemacht. Abstürze und dergleichen habe ich nie gehabt. Weder bei der GUI noch mit dem Kompilat. Webfehler schrieb: > Ich habe damit mal ein paar GUIs versucht zu > bauen, da kam nur instabiler Müll bei raus, fast so wie das Original dto., kann ich nicht nachvollziehen. ich muß aber zugeben, daß ich unter Linux entwickle. Wie es unter Windows aussieht kann ich nicht sagen.
:
Bearbeitet durch User
Max S. schrieb: > Wie kommt es, das von vielen Pascal/Lazarus/Delphi oft als > Anfängersprache bezeichnet wird? Naja, weil es genau dafür konzipiert wurde -- quasi als eine Art anderes C, ohne dessen (durchaus mannigfaltigen) Stolpersteine. > Tatsächlich hat sich Pascal genauso wie C und C++ seit damals > weiterentwickelt. Klar. > Liegt es daran, das viele, als es Borland damals mit Pascal für Windows > vermasselt hatte, auf C umgestiegen sind, und gar nicht gemerkt haben, > das der Fehler von Borland von anderen ausgemerzt wurde, dadurch das > sich das Sterben von Borland so lange hingezogen hatte? Nein. > Ich finde nach wie vor, das Lazarus/Deplhi/PAscal unschalgbar für die > meisten Anwendungen ist. Für reine Anwendungsprogramme ist das schon ziemlich gut, aber im Bereich der Systemsoftwareentwicklung sieht das ein bisschen anders aus. Man kann systemnahe Software natürlich auch mit Pascal, Delphi oder Lazarus bauen, aber moderne Betriebssysteme sind nahezu alle in C-Dialekten geschrieben, und die passen nun einmal am Besten zu C und C++. > In C++ sehe ich eigentlich nur MS Visual C++ als vergleichbar, was das > schnelle Erstellen von Programmen angeht Für Prototyping und RAD haben die interpretierten Sprachen gewonnen, tut mir leid. MSVC und MSVC++ sind ganz nett, aber was die können, können Qt und andere moderne Frameworks auch, das ist schon lang nichts Besonderes mehr. Was Du meinst ist jedoch auch nicht die Technik, sondern nur deren IDE. Und um shiqqe GUIs zusammen klicken... das kann heute ja jeder.
Sheeva P. schrieb: > aber moderne Betriebssysteme sind nahezu alle in > C-Dialekten geschrieben, und die passen nun einmal am Besten zu C und > C++. Du weisst aber schon, dass der Computer kein C oder Pascal Code ausführt, sondern kompilierten Maschinencode? Natürlich kannst Du in Freepascal Deine GUI mit Qt5 bauen, welches in C geschrieben ist, und auch C-Libs einbinden. Und meinem ATmega ist es auch egal, ob das Programm in ASM, C oder Freepascal geschrieben ist. Nur mir nicht. Ich hab letztens eine komplexe Steuerung von C auf Pascal übertragen, inklusive I2C, Uart, LCDisplay, und es war ein Genuß.
Karl schrieb: > Sheeva P. schrieb: >> aber moderne Betriebssysteme sind nahezu alle in C-Dialekten > > Du weisst aber schon, dass der Computer kein C oder Pascal Code > ausführt, sondern kompilierten Maschinencode? Ach Gottchen. Du weißt natürlich auch, daß ich das weiß, oder? > Natürlich kannst Du in Freepascal Deine GUI mit Qt5 bauen, welches in C > geschrieben ist, und auch C-Libs einbinden. Selbstverständlich, das ist ja nur ein ABI. Aber daß es zwar möglich ist, aber mehr Aufwand ist, in C geschriebene ABIs in Freepascal zu verwenden, also das... das weißt Du doch sicher auch? http://wiki.freepascal.org/libc_unit > Und meinem ATmega ist es auch egal, ob das Programm in ASM, C oder > Freepascal geschrieben ist. Nur mir nicht. Ich hab letztens eine > komplexe Steuerung von C auf Pascal übertragen, inklusive I2C, Uart, > LCDisplay, und es war ein Genuß. Du bist wirklich ein lustiger Stalker... Aber Software zu schreiben, die auf einem Betriebssystem laufen soll, ist immer noch etwas anderes, als Software zu schreiben, die ein Betriebssystem ist. U get the idea.
und dennoch liefen die ersten Apple Betriebssysteme witzigerweise in Pascal :-) zu einer Zeit wo Pascal wirklich noch nicht so der Hit war. Richtig gut wurde Pascal ja ab V6 oder so
Max S. schrieb: > und dennoch liefen die ersten Apple Betriebssysteme witzigerweise in > Pascal :-) Ganz bestimmt nicht. Pascal ist vielleicht auf dem Apple durch das UCSD Pascal bekannt geworden. Die Idee dahinter, das auf p-Code laufen zu lassen fand ich damals genial. Edit: Gerade gesehen: Du hast Recht. Das hätte ich jetzt nicht gedacht, daß man mit Pascal ein BS geschrieben hatte.
:
Bearbeitet durch User
Max S. schrieb: > und dennoch liefen die ersten Apple Betriebssysteme witzigerweise in > Pascal :-) zu einer Zeit wo Pascal wirklich noch nicht so der Hit war. Das erste Betriebssystem von Apple war Apple DOS und komplett in Assembler geschrieben. Du beziehst dich auf das OS für den Apple Lisa, der aber wohl eher als Experiment angesehen ist, nahezu unverkäuflich war und schon nach einem Jahr durch seinen Nachfolger, den Macintosh abgelöst wurde. Dessen OS war wiederum komplett in Assembler geschrieben. Ich vermute stark, dass auch beim Lisa OS der Kernel, die Treiber, die Grafikprimitive für die Fensteroberfläche u.ä. weitgehend in Assembler implementiert wurden. Soll nicht dieses Jahr der Quellcode veröffentlicht werden? Da könnte man ja nachschauen.
was ja nichts daran ändert, das auch damals Pascal für inovative Projekte eingesetzt wurde. Das Lisa ein Flop wurde, hatte bekanntermaßen andere Gründe. Im Detail weiß ich es natürlich auch nicht, was genau alles in Pascal geschrieben wurde. Es ist aber so oder so ein gutes Gegenbeispiel, für die die meinen, Pascal taugte damals nichts. Apple Lisa https://www.youtube.com/watch?v=RW25-OuoFIk
:
Bearbeitet durch User
Max S. schrieb: > Wie kommt es, das von vielen Pascal/Lazarus/Delphi oft als > Anfängersprache bezeichnet wird? > Tatsächlich hat sich Pascal genauso wie C und C++ seit damals > weiterentwickelt. Nein, die Gründe liegen ganz woanders. Pascal ist eine Programmiersprache, die man auch als Nicht-Programmierer so einigermaßen lesen kann. Zumindest ergibt sich der Sinn bei biederer Schreibweise und nicht allzu komplexen Konstrukten auch dem Uneingeweihten. Bei C ist das völlig anders, da muß man zuerst ne Menge lernen, um einen C-Quelltext überhaupt lesen zu können. Das ist der Unterschied - und mir sind schon viele Programmierer untergekommen, die ganz erheblichen Wert darauf legten, daß man als Chef ihre Machwerke möglichst NICHT verstehen kann, weil sie sich dadurch für unabkömmlich hielten. Ich kann das verstehen, schließlich ist die Angst um den eigenen Arbeitsplatz schwerwiegender für den Einzelnen als die Lesbarkeit der Quellen. Und genau deshalb war C bei beruflichen Programmierern so beliebt. Was daraus geworden ist - Pufferüberläufe auf dem Stack als Viren-Einfallstore, vergeigte Pointer usw. - ist ja aus den letzten Jahrzehnten sattsam bekannt. Hier haben wir einen Interessenkonflikt, den man eigentlich nicht ausräumen kann. Vermeintliche Sicherung des eigenen Arbeitsplatzes auf der einen Seite, C als fast die einzige Programmiersprache auf der anderen Seite - wobei das Schlimme an C ist, daß C im Gegensatz zu Pascal erwiesenermaßen NICHT renovierungsfähig ist. Das Debakel um die Integer-Typen per Headerdatei anstelle der Renovierung der Compiler ist ein beredtes Beispiel dafür. Nun ist dieser Übelstand vielen C-Programmierern durchaus bewußt, weswegen immer mal wieder "neue" Sprachen erfunden werden, die aber alle aussehen wie durch den Fleischwolf gedrehtes C, weil sie im Grunde nur Pre-Compiler zu C hin sind. Abgesehen von alledem finde ich eine Monokultur sowohl in der HW als auch bei den Programmiersprachen einfach SCHLECHT. Da schert mich auch nicht, daß C-Programmierer, die von dem heutigen Pascal keine Ahnung haben und Delphi oder Lazarus (als IDE's) mit Pascal als Sprache verwechseln, sich herablassed über Pascal äußern. Auf dem PC ist sowohl Delphi als auch Lazarus schlichtweg unschlagbar, denn es bietet ein ordentliches GUI und eine mächtige Programmiersprache und es liefert ne standalone EXE, die ohne fette Runtime-Systeme wie QT oder .Net oder Java usw. auskommt. Die Ablehnung von Pascal ist also letztlich reine Borniertheit. W.S.
W.S. schrieb: > Pascal ist eine Programmiersprache, die man auch als Nicht-Programmierer > so einigermaßen lesen kann. Zumindest ergibt sich der Sinn bei biederer > Schreibweise und nicht allzu komplexen Konstrukten auch dem > Uneingeweihten. Na ja, beim verwendeten Object Pascal würde ich das nicht so unterschreiben. Das gilt vielleicht für die 1975er Pascal Urversion. Wenn man sich auf diese Sprachelemente beschränken würde, dann würde das programmieren damit keinen Spaß mehr machen. > Auf dem PC > ist sowohl Delphi als auch Lazarus schlichtweg unschlagbar, so sehe ich das auch.
W.S. schrieb: > und es liefert ne standalone EXE, die ohne fette Runtime-Systeme Wie schon mehrfach dargelegt, ist das auch mit C- bzw. C++-Compilern exakt genauso möglich. Das ist also kein Vorteil von Pascal.
Rufus Τ. F. schrieb: > Das ist also kein Vorteil von Pascal. Er spricht in diesem Zusammenhang von Delphi/Lazarus.
W.S. schrieb: > Pascal ist eine Programmiersprache, die man auch als Nicht-Programmierer > so einigermaßen lesen kann. Zumindest ergibt sich der Sinn bei biederer > Schreibweise und nicht allzu komplexen Konstrukten auch dem > Uneingeweihten. Bei C ist das völlig anders, da muß man zuerst ne Menge > lernen, um einen C-Quelltext überhaupt lesen zu können. > > Das ist der Unterschied - und mir sind schon viele Programmierer > untergekommen, die ganz erheblichen Wert darauf legten, daß man als Chef > ihre Machwerke möglichst NICHT verstehen kann, weil sie sich dadurch für > unabkömmlich hielten. Glaube ich nicht. > Ich kann das verstehen, schließlich ist die Angst um den eigenen > Arbeitsplatz schwerwiegender für den Einzelnen als die Lesbarkeit der > Quellen. Wirren Code kann man in jeder Sprache fabrizieren, dazu benötigt man kein C :-) Und da helfen auch "Begin" und "End" nicht weiter. > Und genau deshalb war C bei beruflichen Programmierern so beliebt. Nein, C war und ist vor allem beliebt, weil 1.) es dafür einfach mit riesigem Abstand den meisten Quellcode im Netz gibt 2.) man damit sehr kompakten Code schreiben kann - was aber natürlich immer zu Lasten der Lesbarkeit geht. Dort einen guten Kompromiss zu finden zeichnet einen guten Programmierer aus. Knifflige Stellen sollte man schön auseinanderziehen und sorgfältig Dokumentieren, Allerweltssachen kann man knackig und kompakt aufschreiben. 3.) C-Compiler für jede Plattform verfügbar sind: wenn es nur einen Compiler gibt, dann ist das mit ziemlicher Sicherheit ein C-Compiler > Was > daraus geworden ist - Pufferüberläufe auf dem Stack als > Viren-Einfallstore, vergeigte Pointer usw. - ist ja aus den letzten > Jahrzehnten sattsam bekannt. Klar, das ändert aber nichts an den obigen Punkten. > Abgesehen von alledem finde ich eine Monokultur sowohl in der HW als > auch bei den Programmiersprachen einfach SCHLECHT. Ja, das stimmt - wobei es schon viele Programmiersprachen gibt. Hier wird bspw. 90% der Arbeit (auch auf Mikrocontrollern) in Tcl/Tk erledigt. > Da schert mich auch nicht, daß C-Programmierer, die von dem heutigen > Pascal keine Ahnung haben und Delphi oder Lazarus (als IDE's) mit Pascal > als Sprache verwechseln, sich herablassed über Pascal äußern. Auf dem PC > ist sowohl Delphi als auch Lazarus schlichtweg unschlagbar, denn es > bietet ein ordentliches GUI und eine mächtige Programmiersprache und es > liefert ne standalone EXE, die ohne fette Runtime-Systeme wie QT oder > .Net oder Java usw. auskommt. Das kannst Du alles auch in C und bspw. auch in Tcl und vielen anderen Sprachen haben. > Die Ablehnung von Pascal ist also letztlich reine Borniertheit. Nein, das sind schon handfeste Gründe - die Angst um den Arbeitsplatz gehört sicher nicht dazu. Hier bei uns schon gar nicht ;-)
W.S. schrieb: > Pascal ist eine Programmiersprache, die man auch als Nicht-Programmierer > so einigermaßen lesen kann. Zumindest ergibt sich der Sinn bei biederer > Schreibweise und nicht allzu komplexen Konstrukten auch dem > Uneingeweihten. Bei C ist das völlig anders, da muß man zuerst ne Menge > lernen, um einen C-Quelltext überhaupt lesen zu können. Klar. Das war für mich einer der Gründe auf C zu wechseln: Man tippt sich die Finger wund. 1 Seite Pascal ~ 1 Zeile C. Übersichtlicher ist so eine Pascal-Litanei nicht.
:
Bearbeitet durch User
Joachim D. schrieb: > W.S. schrieb: >> Pascal ist eine Programmiersprache, die man auch als Nicht-Programmierer >> so einigermaßen lesen kann. Zumindest ergibt sich der Sinn bei biederer >> Schreibweise und nicht allzu komplexen Konstrukten auch dem >> Uneingeweihten. Bei C ist das völlig anders, da muß man zuerst ne Menge >> lernen, um einen C-Quelltext überhaupt lesen zu können. > > Klar. Das war für mich einer der Gründe auf C zu wechseln: Man > tippt sich die Finger wund. 1 Seite Pascal ~ 1 Zeile C. > Klar geht das Schreiben des Quelltextes in C schneller. Dafür muß man dann eben wesentlich mehr Zeit für die Fehlersuche aufwenden. Das ist dann Ökonomie. Deshalb: Pascal! Lieber in Ruhe einen Quelltext geschrieben, den man auch in 10 Jahren noch versteht als so eine durch den Wolf gedrehte Sonderzeichensammlung.
Mein aktuelles Programm besteht aus >22000 Zeile C-Code, relativ kompakt geschrieben. In Pascal wären das endlose Tapeten.
Na dann mal: wer von euch Lazarus Fans benutzt das professionell?
Ich frage mich warum das jetzt in einen Streit Pascal-C ausartet. Ich arbeite mit beidem: Desktop Anwendung mit GUI -> Pascal uC oder Treiber ect. -> C
ich arbeite zumindest bei µC beruflich mit Pascal. Ich verstehe Deine Frage auch nicht...eine Menge nutzen Pascal beruflich. Es gibt etliche kommerzielle Programme die in Delphi geschrieben sind..also muss es auch genug geben die das beruflich nutzen-oder?!
dumdidum (nicht angemeldet) schrieb: > Na dann mal: wer von euch Lazarus Fans benutzt das professionell? Ohne das Wort „Fan“ zu gebrauchen. Ich benutze Pascal beruflich sowohl auf der PC Seite (Delphi) und auf der Mikrocontrollerseite (mikroPascal PRO).
Entwickele als Freiberufler unter anderem für eine Firma kleine GUI Tools (Berechnungstools, HMIs zur Kommunikation mit Hardware, ...). Sind alle in Lazarus entwickelt. Kann ich prima unter Linux entwickeln und final für deren Windowsumgebung kompilieren. Bin sehr zufrieden. Hatte vor vielen Jahren mit Turbo Pascal angefangen als C-Compiler für PCs noch sehr teuer waren und so eine Affinität bleibt erhalten. Und ja, muss die Programme für die Hardware auch in C schreiben - fällt mir aber auch deutlich schwerer. Gerhard
Karl schrieb: > Natürlich kannst Du in Freepascal Deine GUI mit Qt5 bauen, welches in C > geschrieben ist, und auch C-Libs einbinden. Die Möglichkeit C-Bibliotheken einzubinden haben glücklicherweise viele Programmiersprachen. Das hilft dir nur bei Bibliotheken wie Qt, die in C++ geschrieben sind, alleine nicht viel.
Chris D. schrieb: > man damit sehr kompakten Code schreiben kann - was aber natürlich immer > zu Lasten der Lesbarkeit geht. Begin und end und co stellen eine überflüssige Grundlast da, die die Lesbarkeit herabsetzen, sobald man nicht mehr blutiger Anfänger ist. Bei kleinen abgeschlossen Projekten mit ein paar tausend Zeilen mag das egal sein. Es hat einen Grund, warum Punkt und Komma in Sätzen klein sind, analog zu klammern in C. Und vor einer Überschrift steht nicht Überschrift.
Joe G. schrieb: > Ich benutze Pascal beruflich sowohl auf der PC Seite (Delphi) Delphi waer mir halt zu teuer und die Frage isr wie lange da noch neue Versionen verfuegbar sein werden. DasDelphi professionell einsetzbar ist, ist klar. Ich wollte nur wissen ob lazarus so weit ist.
Achim S. schrieb: > Begin und end und co stellen eine überflüssige Grundlast > da, die die Lesbarkeit herabsetzen, sobald man nicht mehr > blutiger Anfänger ist. [...] > Es hat einen Grund, warum Punkt und Komma in Sätzen klein > sind, analog zu klammern in C. Kurioserweise stimmt das. Lange Zeit war ich auch der Meinung, dass es die Überbetonung der Sonderzeichen ist, die C so unlesbar macht -- bis mir zwei Gegenargumente aufgefallen sind: 1. Die Satzstruktur in natürlichen Sprachen wird, wie Achim korrekt feststellte, ebenfalls durch Sonderzeichen (Interpunktion) und nicht durch Schlüsselworte codiert. 2. Zu den verbreitetsten "Sonderzeichen-Codes" gehört (neben den Verkehrszeichen) sicherlich die Notenschrift in der Musik. Abgesehen von kleinen Kindern, die sich die Tonnamen auf die Klaviertasten schreiben, kenne ich wirklich niemanden, der sich ernsthaft eine "Klartext-Beschreibung" statt der Notenschrift wünscht. (Tabulaturen sind für mich noch kein Klartext.) Dass C Scheisse ist, kann somit nicht primär an den Sonderzeichen liegen :)
Andreas B. schrieb: > Ich frage mich warum das jetzt in einen Streit Pascal-C ausartet. Freitag? Achim S. schrieb: > Begin und end und co stellen eine überflüssige Grundlast da, die die > Lesbarkeit herabsetzen, sobald man nicht mehr blutiger Anfänger ist. Wenn es für Dich ein Problem ist statt {} begin end zu schreiben dann hast Du wirklich ein Problem. Achim S. schrieb: > Bei > kleinen abgeschlossen Projekten mit ein paar tausend Zeilen mag das > egal sein. Wenn Du bei Enterprise Applications noch über {} oder begin end nachdenkst, dann hat Deine Firma ein Problem. /regards
:
Bearbeitet durch User
dumdidum (nicht angemeldet) schrieb: > Na dann mal: wer von euch Lazarus Fans benutzt das professionell? Ich benutze es beruflich, Zwei dutzend GUI-Tools für Produktions- oder Prüfvorrichtungen die wir intern benutzen (teils für Linux, teils für Windows) und Firmware-Updater die wir rausgeben sind mit Lazarus erstellt. Der Grund ist einfach: es existiert auf diesem Planeten einfach kein zweites Tool mit allen(!) diesen Features: cross Platform, GUI, nativ und ohne Runtime Libs, exzellenter GUI-Designer, exzellente IDE. Und daß Object Pascal-Code länger oder mehr zu schreiben wäre als vergleichbares C++ ist übrigens ausgemachter Bullshit. Die beiden Sprachen geben sich im Bezug auf Codeumfang nichts da beide ziemlich gleich mächtig im Sprachumfang sind und die Hälfte der Schreibarbeit macht sowieso die IDE (Methoden oder Interfaces implementieren, Eventmethoden generieren, zu jedem begin/end hinschreiben, etc. muss keiner von Hand machen). Und begin hab ich auf ner deutschen Tastatur schneller hingeschrieben als mir bei der geschweiften Klammer die Finger zu verrenken.
:
Bearbeitet durch User
Andreas H. schrieb: > Achim S. schrieb: >> Begin und end und co stellen eine überflüssige Grundlast >> da, die die Lesbarkeit herabsetzen, sobald man nicht mehr >> blutiger Anfänger ist. > > Wenn es für Dich ein Problem ist statt {} begin end zu > schreiben dann hast Du wirklich ein Problem. Versuche doch statt der reflexhaften Herabsetzung des Diskussionspartners ausnahmsweise mal eine sachliche Entgegnung Doppelpunkt Wenn Interpunktion in Form von Schlüsselworten Klammerauf statt Sonderzeichen Klammerzu wahrnehmungspsychologisch günstig wäre Bindestrich warum verwenden natürliche Sprachen dann doch Sonderzeichen dafür Fragezeichen Es ist nicht primär ein Problem des Fettruck Schreibens Fettdruckaus Komma sondern des Fettdruck Lesens Fettdruckaus Punkt Das ist viel schwerwiegender Komma weil jeder Text Bindestrich und Quelltexte sind auch Texte Bindestrich öfter gelesen als geschrieben wird Punkt > Achim S. schrieb: >> Bei kleinen abgeschlossen Projekten mit ein paar >> tausend Zeilen mag das egal sein. > > Wenn Du bei Enterprise Applications noch über {} oder > begin end nachdenkst, dann hat Deine Firma ein Problem. Nein: Da generell zu wenig über {} oder begin end nachgedacht wird, haben alle Branchen ein Problem, die Computer einsetzen. Die Fehlentscheidungen von heute sind die Geschäftsgrundlage von morgen :)
Dass in Windows immer diese runtimes installiert sein müssen vor jedem Starten eines selber gemachten Programms ist auch etwas seltsam.
Joachim D. schrieb: > Mein aktuelles Programm besteht aus >22000 Zeile C-Code, > relativ kompakt geschrieben. In Pascal wären das endlose > Tapeten. Unsinn, man kann auch in ObjectPascal sehr "kompakten" Quelltext schreiben. Allerdings: Nur Masochisten und Idioten tun sich das an... Mit "kompakt" meinen C'ler nämlich typischerweise: unleserlich für jeden anderen und nur mit Mühe leserlich für einen selber. Jedenfalls wenn man länger als zwei Monate nicht in den Quelltext reingeschaut hat. Deswegen ist dieser "kompakte" Code in der professionellen Softwareentwicklung auch in C absolut verpönt, zumal wenn die Software in Teamarbeit entsteht...
Andreas H. schrieb: > Wenn es für Dich ein Problem ist statt {} begin end zu schreiben dann > hast Du wirklich ein Problem. Das Problem ist weniger das Schreiben als das Lesen. Jeder Editor kann { durch begin ersetzen und } durch end. Aber beim Lesen soviel Ballast vorgesetzt zu bekommen, ist einfach nur nervig. Aber wer's ballastreich mag, kann es auch in C so schreiben. Am Anfang ein
1 | #define begin {
|
2 | #define end }
|
und der Compiler versteht es auch.
Jobst Q. schrieb: > Andreas H. schrieb: >> Wenn es für Dich ein Problem ist statt {} begin end zu >> schreiben dann hast Du wirklich ein Problem. > > Das Problem ist weniger das Schreiben als das Lesen. Jeder > Editor kann { durch begin ersetzen und } durch end. Aber > beim Lesen soviel Ballast vorgesetzt zu bekommen, ist > einfach nur nervig. Naja, es ist nervig, weil es codierungstechnisch schlecht ist. Sehr viele Codes und Übertragungssysteme kennen neben den Nutzdatensymbolen noch irgendwelche Steuercodes, die primär den Decoder steuern sollen und den Nutzdatenstrom strukturieren. In der natürlichen Sprache ist das die Interpunktion. Kein normaler Mensch will eine Interpunktion mittels Schlüsselworten. Das war mMn eine der wenigen echten Fehlentscheidungen von Wirth.
Zenbtrales Problem von Pascal war und ist, daß der Standard vollkommen
unbrauchbar war und sich daher jede Implementation was Eigenes
zurechtgefrickelt hat - was dann aber zu keiner anderen Implementierung
kompatibel war.
Das ist heute immer noch so, und mit Freepascal sitzt man dann auf einer
Insel fest. Mit C ist das nicht so, weil es brauchbare Standards gibt
und die implementiert werden.
Zudem hat man dadurch auch mit Legacy-Code keine Probleme, weil man
jedem C-Compiler sagen kann, nach welchem Standard er denn compilieren
soll, was bei Pascal mangels brauchbarer Standards prinzipbedingt nie
geht.
Dann die Sprache selber, die zu Lehrzwecken mit ihrem sehr strikten
Typensystem zwar gut war, in der Praxis aber genau dadurch oft genug im
Weg herumstand. Das ging soweit, daß Arrays gleichen Grundtyps, aber
verschiedener Länge inkompatibel waren, weswegen Strings verschämt in
einem Headerfile als Array immer derselben Länge definiert waren.
Das Ärgernis mit begin/end, was wesentlich schlechter lesbar ist als die
Klammern in C (sioehe Possetjels Posting oben), ist natürlich auch da,
aber IMO nicht so kampfentscheidend. Annehmbarer C-Code ist besser
lesbar als Pascal, und was die C-Obfuskationskünstler verbrechen, wäre
auch in Pascal nicht lesbar.
Ach ja, im originalen Pascal gab es kein break/continue. Das führte
dazu, daß Pascal-Programmierer sich irgendwelche Hilfsflags definiert
haben, die im Schleifenkopf auch noch abgeprüft wurden. Erstens kostete
das Performance, zweitens war es schlechter lesbar.
Man merkt einfach, daß Pascal am grünen Tisch von einem Theoretiker
entworfen wurde, während C von Anfang an den Dogfood-Test bestehen
mußte. ("Eat your own dogfood" = der Entwickler muß seine eigene
Kreation selber benutzen)
Ich kann übrigens beide Sprachen gut vergleichen, weil ich mit
Turbo-Pascal ein paar Jahre programmieren gelernt habe und danach auf C
umgestiegen bin. Das war wie Radfahren lernen und dann die Stützräder
abnehmen: man fliegt ein paarmal hin, aber wenn man den Bogen erstmal
raushat, will man keine Stützräder mehr zurückhaben.
Possetitjel schrieb: > Kein normaler Mensch will eine Interpunktion mittels > Schlüsselworten. Wenn du das wirklich glaubst, bist du definitiv ein Idiot. Schließlich kennt auch C eine Menge Schlüsselwörter, aber offenbar zu wenige, was dazu geführt hat, das manche völlig idiotisch mit völlig unterschiedlicher Bedeutung mehrfach verwendet wurden, man denke nur an "static" oder "void"... Was aber noch viel wichtiger ist: der Zweck einer Programmiersprache ist deren Benutzung durch Menschen und für die ist es nunmal viel einfacher zu lesen: while irgendwas [... sehr viel Scheiß ...] end while in C sieht das dann typisch sehr oft so aus: while (irgendwas) { [... sehr viel Scheiß ...] } //end while Mal ganz abgesehen von den völlig nutzlosen Klammern um das Conditional: der Kommentar allein spricht Bände über den Nutzen einer ausschweifenden Syntax (OK: hier nicht Pascal, sondern VB.NET)... Und: im Gegensatz zu dem Kommentar in C, brauche ich das "end while" in VB.net nicht selber hinschreiben, das nimmt mir die Code Completion mit zwei Tastenanschlägen ab... So und nun rechne einfach mal selber die Tastenanschläge für diesen Strukturrahmen zusammen: Wenn du nicht völlig blöd bist, wirst du erkennen: VB.net ist effizienter als C. Zumindest beim Schreiben des Codes, beim Lesen sowieso. Nur in der Ausführungsgeschwindigkeit ist C im Vorteil, allerdings: je nach Umständen irgendwas zwischen kaum merklich bis hin zu sehr deutlich. Naja, bei ObjectPascal ist's natürlich auch nicht ganz so schick. Statt der "}"-Pyramide mit Kommentaren, was da eigentlich zu Ende ist von C, hat man bei OP halt die Pyramide von "end", auch mit Kommentaren, was da eigentlich jeweils zu Ende ist...
Max S. schrieb: > Wie kommt es, das von vielen Pascal/Lazarus/Delphi oft als > Anfängersprache bezeichnet wird? Von wem bitte?
Bla schrieb: > Dass in Windows immer diese runtimes installiert sein müssen vor jedem > Starten eines selber gemachten Programms ist auch etwas seltsam. Wie oft denn noch? Nein, das muss bei C- oder C++-Programmen nicht so gemacht werden. Es kann so gemacht werden. Bei den .Net-Sprachen sieht das anders aus, die kommen ohne ihre Laufzeitumgebung nicht aus, aber um die geht es hier ja auch nicht. c-hater schrieb: > Mal ganz abgesehen von den völlig nutzlosen Klammern um das Conditional Daß Du keine Ahnung von C hast, hast Du ja bereits mehrfach bewiesen, warum machst Du das jetzt schon wieder? Nehmen wir mal folgendes Beispiel:
1 | while (t = --i) |
2 | x = j++; |
Nach Deiner genialen Interpretation müsste das also auch so geschrieben werden können:
1 | while t = --i |
2 | x = j++; |
Und da der Zeilenumbruch nur optischer Zucker ist, also auch so:
1 | while t = --i x = j++; |
Hey, das ist ... Vorschlag zur Güte: Lass' Dich einfach über Dinge aus, von denen Du Ahnung hast. Da gibt es ja ein paar, wo Du das erfreulicherweise auch unter Beweis gestellt hast. Aber die C-Syntax? Nein.
Keiner N. schrieb: > Jetzt bin ich mal gespannt. Wie lautet denn die mehrfache Verwendung? Wenn du das noch nichtmal gerafft hast, kannst du definitiv kein C. Weil: schon bei recht kleinen Programmen stößt man fast unweigerlich auf diesen grenzdebilen Turbo-Schwachsinn. Siehe "void*" vs. "void functionname(void)". Dreimal "void", jeweils in einer völlig anderen Bedeutung. Sowohl semantisch als auch physisch... Ich überlasse es dir selber, in deinen weiteren Bemühungen, deine präferierte Programmiersprache auch tatsächlich irgendwann mal zu erlernen, auch dieses Geheimnis zu lüften...
Rufus Τ. F. schrieb: > Nehmen wir mal folgendes Beispiel: > >
1 | > while (t = --i) |
2 | > x = j++; |
3 | >
|
Das ist böse. Geht garnicht. Heute werden die curly braces (die du hier weggelassen hast) in der Praxis praktisch zwingend gefordert. Nötig sind sie bei allem, was mehr als ein Einzeiler ist, ja sowieso. Zwingend gefordert werden sie nur noch nicht von vom aktuellen (aber immer noch eher historischen) C-Standard. Aber das wird sicher kommen. Für jeden, der logisch denken kann und die Entwicklung des Sprachstandards verfolgt, liegt das völlig klar auf der Hand... > Vorschlag zur Güte: Lass' Dich einfach über Dinge aus, von denen Du > Ahnung hast. Da gibt es ja ein paar, wo Du das erfreulicherweise auch > unter Beweis gestellt hast. Aber die C-Syntax? Nein. Doch. Du vergißt immer wieder, dass ich ein guten Teil meines Einkommens mit Code in C verdiene. Ich kann C (so gut man das halt können kann). Mit Sicherheit kann ich C besser als 90% aller Leute, die in C programmieren. Und eben weil ich diesen Scheiß kann, weiß ich auch um die massiven Schwächen dieser Altlast der Evolution der Software-Entwicklung...
Rufus Τ. F. schrieb: > Nehmen wir mal folgendes Beispiel: > while (t = --i) > x = j++; Naja, aus meiner Sicht entbehrt es nicht einer gewissen Willkür, dass das ausgerechnet RUNDE Klammern sind. Wenn Blöcke in geschweifte Klammern eingeschlossen werden -- warum dann nicht auch die Schleifenbedingung? Und in der Tat sieht es in mindestens einer Programmier- sprache (Name ist dem Autor bekannt) genau so aus:
1 | while { ... } {
|
2 | ... |
3 | } |
Das hat überdies den Charme, dass der Weg zu MISRA-kombatiblem Code nicht mehr sehr weit ist... :)
Possetitjel schrieb: > Blöcke in geschweifte Klammern eingeschlossen werden -- > warum dann nicht auch die Schleifenbedingung? Weil eines "Block" und das Andere "Bedingung" ist - schön zu unterscheiden :-)
c-hater schrieb: > Zwingend gefordert werden sie nur noch nicht von vom aktuellen (aber > immer noch eher historischen) C-Standard. Welcher C++-Standard fordert das denn Deiner Ansicht nach? > Aber das wird sicher kommen. Für jeden, der logisch denken kann und die > Entwicklung des Sprachstandards verfolgt, liegt das völlig klar auf der > Hand... Für Leute, die so von Ahnung in Sachen C nur so durchtränkt sind wie Du. -- Nein, natürlich will ich das von mir erwähnte Konstrukt nicht als nachahmenswert oder besonders toll darstellen, aber es ist perfekt legales C, perfekt legales C++ und im übrigen auch perfekt legales Java (bis auf die Einschränkung, daß "t" ein bool sein müsste). Possetitjel schrieb: > Naja, aus meiner Sicht entbehrt es nicht einer gewissen Willkür, dass > das ausgerechnet RUNDE Klammern sind. Weil das eben kein Block ist, sondern ein Ausdruck.
Leider ist das Beispiel mit dem fehelnden Standard auch ein immer wieder wiederholter Fehler. Der Standsrd für Pascal ist Delphi...warum da nie zur Kenntnis genommen wird verstehe auch nicht. Evtl braucht der typisch Deutsche immer DIN normen und Regeln? damit etwas als Standard verstanden wird
Rufus Τ. F. schrieb: > Possetitjel schrieb: >> Naja, aus meiner Sicht entbehrt es nicht einer gewissen >> Willkür, dass das ausgerechnet RUNDE Klammern sind. > > Weil das eben kein Block ist, sondern ein Ausdruck. Ach. Und Ausdrücke werden in C generell in runde Klammern eingeschlossen?
Ich kann Eure Argumentiererei nicht wirklich nachvollziehen. Die Leute können doch ruhig in der Sprache ihrer Wahl programmieren die ihnen liegt. Wenn der AG auf etwas anderes besteht dann hat derjenige eben Pech gehabt und müßte sich anpassen wenn er dort bestehen will. Diejenigen die nicht mit der Zeit gehen wollen machen eben Platz für diejenigen die Mit der Zeit gehen.
:
Bearbeitet durch User
Possetitjel schrieb: > Und Ausdrücke werden in C generell in runde Klammern eingeschlossen? Im Zusammenhang mit while oder if ist das so üblich. Auch der Dreifach-Ausdruck von for wird in runden Klammern geschrieben. Überrascht Dich das jetzt? Jedenfalls kann weder bei if, while, for oder auch einem Funktionsaufruf ein Block angegeben werden.
Dieter F. schrieb: > Possetitjel schrieb: >> Blöcke in geschweifte Klammern eingeschlossen werden -- >> warum dann nicht auch die Schleifenbedingung? > > Weil eines "Block" und das Andere "Bedingung" ist - > schön zu unterscheiden :-) Nein. Völlig willkürlich. Ich kann in der Festlegung keinerlei wohlbegründeten sachlichen Sinn erkennen. Der Compiler muss sowieso wissen, dass das "while" zwei Argumente braucht, nämlich eine Bedingung und einen Anweisungsblock. Warum festgelegt wurde, dass das eine mit runden Klammern einzuschließen ist, das andere aber (manchmal) mit geschweiften, ist für mich logisch nicht nachvollziehbar. Es geht mir nicht darum, DASS das so festgelegt wurde. Es geht mir darum, dass ich in der Festlegung keinen logischen Sinn sehe.
Rufus Τ. F. schrieb: > Possetitjel schrieb: >> Und Ausdrücke werden in C generell in runde Klammern >> eingeschlossen? > > Im Zusammenhang mit while oder if ist das so üblich. > Auch der Dreifach-Ausdruck von for wird in runden > Klammern geschrieben. Ja -- und welchen Zweck hat diese Üblichkeit? Außer dem natürlich, syntaktisch korrekten C-Code zu produzieren... :) > Überrascht Dich das jetzt? Nein. C strotzt vor Inkonsistenzen, da kommt es auf eine mehr oder weniger nicht an. > Jedenfalls kann weder bei if, while, for oder auch > einem Funktionsaufruf ein Block angegeben werden. Ich weiss. Und meine Frage ist: WARUM nicht? Ich frage nicht nach dem historischen Grund "Weil K&R das vor dreihundert Jahren so festgelegt haben", sondern nach einem auch heute noch gültigen LOGISCHEN Grund. WARUM ist es für den Compiler und/oder für den Programmierer wichtig, an dieser Stelle syntaktisch zwischen Ausdrücken und Anweisungsblöcken zu unterscheiden? In Tcl ist das nämlich nicht erforderlich, also folgere ich daraus, dass es sich um eine der zahllosen willkürlichen Eigenarten von C handelt.
Possetitjel schrieb: > Lange Zeit war ich auch der Meinung, dass es die Überbetonung > der Sonderzeichen ist, die C so unlesbar macht -- bis mir > zwei Gegenargumente aufgefallen sind: > > 1. Die Satzstruktur in natürlichen Sprachen wird, wie Achim > korrekt feststellte, ebenfalls durch Sonderzeichen > (Interpunktion) und nicht durch Schlüsselworte codiert. > > 2. Zu den verbreitetsten "Sonderzeichen-Codes" gehört (neben > den Verkehrszeichen) sicherlich die Notenschrift in der > Musik. Weitere Beispiele: 3. Mathematik: Schon Grundschüler lernen die Symbole +, −, · und :. Hier hat selbst Wirth eingesehen, dass a := b + c (Pascal) wohl irgendwie leichter zu erfassen ist als add b to c giving a (Cobol) 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. 5. Verkehrsschilder: Wie sähe wohl die Unfallstatistik aus, wenn man alle ⛛ an Kreuzungen durch Tafeln mit der Aufschrift "Hier müssen Sie dem Querverkehr Vorrang gewähren!" ersetzen würde? Symbole benutzte der Mensch schon lange bevor er Buchstaben zu Wörtern zusammengesetzt hat. Mittelfeld-Regisseur schrieb: > Klar geht das Schreiben des Quelltextes in C schneller. Dafür muß man > dann eben wesentlich mehr Zeit für die Fehlersuche aufwenden. Das ist > dann Ökonomie. > > Deshalb: Pascal! Du kannst auch beides gleichzeitig haben und sogar noch mehr: Im Vergleich zu C nur einen Bruchteil der Quelltextgröße und im Vergleich zu Pascal eine um ein Vielfaches höhere Fehlerdetektion bereits zur Compilezeit. Ich möchte jetzt aber nicht noch weitere Programmiersprachen in die Diskussion kippen, sonst wird's bald zu unübersichtlich :)
Possetitjel schrieb: > In Tcl ist das nämlich nicht erforderlich, also folgere > ich daraus, dass es sich um eine der zahllosen willkürlichen > Eigenarten von C handelt. Naja, es ist halt "historisch gewachsen". Wie so vieles andere an Code auch. Überraschend sind eigentlich nur Leute, die eine Quasi-Religion daraus machen, anstatt die Sache abstrakt zu sehen und nach wissenschaftlichen Gesichtspunkten zu bewerten. In aller Regel sind das eben Leute, die nur eine Sprache wirklich können und eigentlich auch garnix anderes lernen wollen. Also selbstbeschränkte Idioten. Ganz sicher ist das nach meiner Erfahrung so im Falle der typischen C-Fetischisten. Die können doch tatsächlich mehr Aufwand in eine (oft nur theoretische) Portabilität stecken als in die Lösung des Problems... Der Erfolg ist dann Code, der theoretisch für jedes Zielsystem übersetzbar ist, praktisch aber auf keinem wirklich läuft. Zumindest auf keinem wirklich gut...
Possetitjel schrieb: > WARUM ist es für den Compiler und/oder für den Programmierer > wichtig, an dieser Stelle syntaktisch zwischen Ausdrücken > und Anweisungsblöcken zu unterscheiden? Ich verstehe zwar den Fundamentalismus dieser Diskussion nicht, aber welche syntaktischen Elemente man verwendet, um die Abgrenzung der Bedingung vom Rest des Codes zu kennzeichnen, ist keine Frage zwingender Logik, sondern schlicht eine des persönlichen Geschmacks desjenigen, der die Sprache definiert. Ob das also if (a == b) oder if {a == b} oder if a = b then heisst, lässt sich nicht streng logisch begründen, so lange es sich dabei um reservierte Tokens handelt. Ebensogut hätte man es if a == b ) definieren können, denn die öffnende Klammer ist eigentlich nur syntaktischer Zucker. Etwas komplizierter wird es bei Sprachen, die keine reservierten Schlüsselwörter kennen. Bei denen also if if = then then legalen Code darstellt (PL/I). Erst recht, wenn man dann auch noch Blanks lustig reinstreuen kann (klassisches Fortran). Dann muss man sich um die Syntax deutlich mehr Gedanken machen, um die Sprache leidlich eindeutig zu kriegen. Die Sache ändert sich ein wenig, wenn man nicht auf der formalen Syntax rumreitet, sondern den Parser in der Implementierung betrachtet. In dem Fall kann man den gleichen Parser-Code für ( ... ) als Teil einer Ausdrucks und als Bedingung von "if" verwenden.
:
Bearbeitet durch User
Possetitjel schrieb: > das > andere aber (manchmal) mit geschweiften, Nö, das ist eindeutig. Wenn nur ein "Befehl/Anweisung" nach einem Ausdruck, dann sind keine geschweiften Klammern erforderlich. Wenn mehrere "Befehle/Anweisungen" nach einem Ausdruck, dann sind geschweifte Klammern erfoderlich. Ist für mich eindeutig, obwohl ich aus anderen "Ecken" (Cobol, PL/1, und ABAP) komme. Merkwürdig für mich ist nur die Praxis, die geschweifte öffnende Klammer direkt nach dem "Ausdruck" zu schreiben - das ist für mich unleserlich (daher pinne ich das alles um). Ich habe anfangs auch erhebliche Probleme mit der "Klammerei" gehabt und deswegen auf dem MC mit Assembler angefangen - aber mittlerweile komme ich damit gut klar und ziehe C dem Assembler (i.d.R.) vor.
c-hater schrieb: > > while irgendwas > [... sehr viel Scheiß ...] > end while > > in C sieht das dann typisch sehr oft so aus: > > while (irgendwas) > { > [... sehr viel Scheiß ...] > } //end while > > Mal ganz abgesehen von den völlig nutzlosen Klammern um das > Conditional: der Kommentar allein spricht Bände über den Nutzen einer > ausschweifenden Syntax (OK: hier nicht Pascal, sondern VB.NET)... Das ist ja echt grandios. "}" braucht gleich 2 Worte und noch besser ist das "{" oder "begin". Das ist (c-hater-style) total kompakt im unsichtbaren "NewLine" versteckt. Das nen ich mal eine ausgereifte Syntax.
c-hater schrieb: > hat man bei OP halt die Pyramide von "end", auch mit Kommentaren, was da > eigentlich jeweils zu Ende ist... 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.
c-hater schrieb: > while irgendwas > [... sehr viel Scheiß ...] > end while > > in C sieht das dann typisch sehr oft so aus: > > while (irgendwas) > { > [... sehr viel Scheiß ...] > } //end while > > Mal ganz abgesehen von den völlig nutzlosen Klammern um das > Conditional: der Kommentar allein spricht Bände über den Nutzen einer > ausschweifenden Syntax (OK: hier nicht Pascal, sondern VB.NET)... Na ja, die eckigen Klammern um "den Scheiß" gibt es in beiden Varianten nicht. Die geschweiften Klammern sind für mich (mittlerweile) praktischer, wie ein "end while" (wobei ein entsprechende Kommentar bei einer ordentlichen IDE sowieso überflüssig ist). Wenn ich mit einem Klick "den Scheiß" ausblenden kann, ist die Logik für mich ausreichend übersichtlich.
Dieter F. schrieb: > ein "end while" Was ist ein "end while", in welcher Sprache gibts denn das? Basic?
Bernd K. schrieb: > Was ist ein "end while", in welcher Sprache gibts denn das? Basic? Frag das bitte C-hater
Yalu X. schrieb: > Symbole benutzte der Mensch schon lange bevor er Buchstaben zu Wörtern > zusammengesetzt hat. Wirth hatte auch Maschinen im Auge, die üblicherweise mit einem 6-Bit Zeichensatz arbeiteten. Der erste Pascal-Compiler lief auf einer solchen. Man kann aber nur Symbole verwenden, die es auch gibt. C geht von 7-Bit ASCII Code im amerikanischen Original aus. Weniger geht nicht. Die früher gerne verwendete Codierung deutscher Umlaute in 7-Bit Code macht aus C einfach nur gequirlte Scheisse: if ( aÄiÜ != 0 ) ä printf("?Ön"); ü Genau deshalb gibts die Trigraphs, aber so arg viel schöner sieht es damit auch nicht aus: if ( a??(i??) != 0 ) ??< printf("???/n"); ??> (Keine Gewähr für Fehlerfreiheit ;-)
Bernd K. schrieb: > Dieter F. schrieb: >> ein "end while" > > Was ist ein "end while", in welcher Sprache gibts denn das? Basic? Der c-hater findet, daß die schräge Syntax von VB.net gut erklärt, warum Pascal besser als C ist. So war er halt schon immer ;-)
A. K. schrieb: > Yalu X. schrieb: >> Symbole benutzte der Mensch schon lange bevor er Buchstaben zu Wörtern >> zusammengesetzt hat. > > Wirth hatte auch Maschinen im Auge, die üblicherweise mit einem 6-Bit > Zeichensatz arbeiteten. Der erste Pascal-Compiler lief auf einer > solchen. > > Man kann aber nur Symbole verwenden, die es auch gibt. C geht von 7-Bit > ASCII Code im amerikanischen Original aus. Weniger geht nicht. Die > früher gerne verwendete Codierung deutscher Umlaute in 7-Bit Code macht > aus C einfach nur gequirlte Scheisse: > if ( aÄiÜ != 0 ) ä printf("?Ön"); ü > Genau deshalb gibts die Trigraphs, aber so arg viel schöner sieht es > damit auch nicht aus: > if ( a??(i??) != 0 ) ??< printf("???/n"); ??> > (Keine Gewähr für Fehlerfreiheit ;-) Also sind begin/end der früher mal herrschenden IT-Steinzeit geschuldet und es besteht heute keine Notwendigkeit mehr für diese, oder? BTW, Trigraphs wurden (sehr zum Ärger der EBCDIC(/Lochkarten-)Fraktion) gerade aus dem C++-Standard gekickt.
c-hater schrieb: > while irgendwas > [... sehr viel Scheiß ...] > end while Neben der Lesbarkeit hat das noch einen anderen Charme. Gegenüber einfachem begin..end oder {..} erlaubt es dem Compiler, bei verhedderter Klammerung freundlich darauf hinzuweisen, dass ein "end if" nicht zu "while" passt. IDEs waren nicht immer so schlau wie heute.
:
Bearbeitet durch User
A. K. schrieb: > Klammernzählerei konnte ziemlich nervend sein. Wenn man vernünftig einrückt nicht - wie bei jeder anderen Programmiersprache auch.
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...
Dieter F. schrieb: > Wenn man vernünftig einrückt nicht - wie bei jeder anderen > Programmiersprache auch. Ich gratuliere deinem Adlerauge, dem auch bei miserablem Font der Unterschied zwischen einem vertippten ) und dem gemeinten } sofort auffällt. Ohne Hilfe einer entsprechenden IDE, wohlgemerkt. ;-)
Dieter F. schrieb: > Wenn ich mit einem Klick "den Scheiß" ausblenden kann, ist die Logik für > mich ausreichend übersichtlich. Das ist ein schönes Beispiel, wozu Redundanz im Quelltext wirklich nützlich ist. Dein schönes Code-Folding fällt nämlich bei C-Quelltexten ganz schnell auf die Schnauze. Eben wegen der fehlenden Redundanz. Ein kleiner Fehler im Body (ein vergessenes Semikolon am Ende einer Zeile genügt) und die ganze Herrlichkeit bricht in sich zusammen...
Carl D. schrieb: > Also sind begin/end der früher mal herrschenden IT-Steinzeit geschuldet > und es besteht heute keine Notwendigkeit mehr für diese, oder? Korrekt. Eigentlich sollte man den APL Zeichensatz verwenden. Da gibts überhaupt keine Schlüsselworte, die gesamte Sprache verwendet nur Symbole. Könnte ich mich schnell dran gewöhnen. ;-)
Carl D. schrieb: > Das ist ja echt grandios. > "}" braucht gleich 2 Worte und noch besser ist das > "{" oder "begin". Das ist (c-hater-style) total kompakt im unsichtbaren > "NewLine" versteckt. Versteckt? Nö. Wie schon gesagt: Programmiersprachen sollen von Menschen benutzt werden. Ein oder zwei unsichtbare Bytes machen den Compiler (genauer: den Parser) nicht wesentlich langsamer und auch den Quelltext nicht wesentlich fetter. Mehr noch: in jedem normalen C-Code finden sich diese Zeilenumbrüche ebenfalls, eben weil es so für Menschen einfach besser lesbar ist. Wo bleibt also der Vorteil der Tatsache, dass man sie theoretisch auch weglassen könnte? Das hat vor gefühlten 100 Jahren vielleicht mal eine Rolle gespielt, heute ist es einfach nur noch idiotisch...
Bernd K. schrieb: > Dieter F. schrieb: >> ein "end while" > > Was ist ein "end while", in welcher Sprache gibts denn das? Basic? Wer zumindest lesen kann, ist bei solchen Diskussionen ganz klar massiv im Vorteil. Sprich: ich habe die Programmiersprache in dem von dir zitierten Posting explizit benannt...
c-hater schrieb: > Dieter F. schrieb: > >> Wenn ich mit einem Klick "den Scheiß" ausblenden kann, ist die Logik für >> mich ausreichend übersichtlich. > > Das ist ein schönes Beispiel, wozu Redundanz im Quelltext wirklich > nützlich ist. Dein schönes Code-Folding fällt nämlich bei C-Quelltexten > ganz schnell auf die Schnauze. Eben wegen der fehlenden Redundanz. Ein > kleiner Fehler im Body (ein vergessenes Semikolon am Ende einer Zeile > genügt) und die ganze Herrlichkeit bricht in sich zusammen... Komisch daß das doch so "schlechte" Eclipse das in C und dem "Syntax-Clone" Java hinbekommt. Irgendwas müssen die richtig machen!?! Aber letztlich ist dieser Sprachen-Streit eh nur eine Frage des persönlichen Geschmacks. Warum sich aber die Einen durch gefühlte Nichtbeachtung der Anderen zurückgesetzt fühlen (siehe Thread-Titel), muß man nicht wirklich verstehen wollen.
Dieter F. schrieb: > Dieter F. schrieb: >> Frag das bitte C-hater > > In VBA scheinbar ... Noch einer, der nichtmal Lesen kann, aber mit den Erwachsenen diskutieren will...
c-hater schrieb: > Eben wegen der fehlenden Redundanz. Ein > kleiner Fehler im Body (ein vergessenes Semikolon am Ende einer Zeile > genügt) und die ganze Herrlichkeit bricht in sich zusammen... Anfänger haben oft Probleme mit schließenden Klammern. Nach einiger Zeit geht das dann weg, ich kann mich nicht erinnern wann ich das letzte mal eine Klammer "vergessen" und nicht binnen 5 Sekunden wieder gefunden habe. Und ich schreibe beruflich den ganzen Tag lang hochkomplexen und umfangreichen "Scheiß". In C und in Object Pascal und auch in Python. Dieses ganze Anfang und Ende des Blockes nicht mehr finden oder Klammer verlieren ist ein konstruiertes Schwachsinnsargument von Leuten die keine Praxis haben. Sowas passiert in der Praxis nicht. Genauso wie die Leute die immerzu behaupten in Python würden über Nacht die Heinzelmännchen die Einrückungen kaputt machen und deshalb sei das Scheiße. Kein Problem in der Praxis, keine Heinzelmännchen, niemand verrutscht was oder klaut heimlich die Klammern. Dieser ganze Themenkomplex ist vollkommen an den Haaren herbeigezogen. Wenn man vernünftig einrückt und alle Einrückungen bei jeder Änderung immer sofort und ordentlich mitpflegt behält man zu jedem Zeitpunkt den Überblick.
c-hater schrieb: > Carl D. schrieb: > >> Das ist ja echt grandios. >> "}" braucht gleich 2 Worte und noch besser ist das >> "{" oder "begin". Das ist (c-hater-style) total kompakt im unsichtbaren >> "NewLine" versteckt. . > Versteckt? Nö. Wie schon gesagt: Programmiersprachen sollen von Menschen > benutzt werden. Ein oder zwei unsichtbare Bytes machen den Compiler > (genauer: den Parser) nicht wesentlich langsamer und auch den Quelltext > nicht wesentlich fetter. Mehr noch: in jedem normalen C-Code finden sich > diese Zeilenumbrüche ebenfalls, eben weil es so für Menschen einfach > besser lesbar ist. Wo bleibt also der Vorteil der Tatsache, dass man > sie theoretisch auch weglassen könnte? > > Das hat vor gefühlten 100 Jahren vielleicht mal eine Rolle gespielt, > heute ist es einfach nur noch idiotisch... Daß sie (die Zeilenumbrüche) in deinem VB.net-Beispiel aber den Part des "begin" übernehmen, hast sicher verstanden, oder?
Possetitjel schrieb: > 1. Die Satzstruktur in natürlichen Sprachen wird, wie Achim > korrekt feststellte, ebenfalls durch Sonderzeichen > (Interpunktion) und nicht durch Schlüsselworte codiert. Satzzeichen dienen dazu, jene Elemente zu codieren, die in der gesprochenen Sprache durch Betonung und Pausen ausgedrückt werden (oder Vokale, wie in Arabisch und Hebräisch). Sobald man darüber hinaus geht, verwenden auch menschliche Sprachen Worte in syntaktischer Rolle. Pascals "if .. then" ist direkt der englischen Sprache nachgebildet, die genau wie Deutsch mit "wenn .. dann" auch Worte zur Strukturierung verwendet.
A. K. schrieb: > Neben der Lesbarkeit hat das noch einen anderen Charme. Gegenüber > einfachem begin..end oder {..} erlaubt es dem Compiler, bei verhedderter > Klammerung freundlich darauf hinzuweisen, dass ein "end if" nicht zu > "while" passt. > > IDEs waren nicht immer so schlau wie heute. Du hast noch nicht die ganze Konsequenz der Existenz von Redundanz im Quelltext verstanden. IDEs sind heute schlau, ja. Aber sie fallen schnell auf die Schnauze, wenn syntaktische Fehler im Code sind. Sie fallen aber umso weniger schnell auf die Schnauze, je mehr syntaktische Redundanz der Code enthält. Gleichzeitig können sie umso bessere und treffsichere Codevervollständigung bieten, je mehr Redundanz der Quelltext enthält. Mein Gott, jeder, dem ich das erst erklären muss, disqualifiziert sich als Programmierer eigentlich selber. Er ist nachweislich unfähig, hinreichend abstrakt-logisch zu denken. Oder halt (aus meiner Sicht viel schlimmer) aus ideologischen Gründen unwillig dazu...
c-hater schrieb: > Du hast noch nicht die ganze Konsequenz der Existenz von Redundanz im > Quelltext verstanden. IDEs sind heute schlau, ja. Aber sie fallen > schnell auf die Schnauze, wenn syntaktische Fehler im Code sind. Sie > fallen aber umso weniger schnell auf die Schnauze, je mehr syntaktische > Redundanz der Code enthält. Und irgendwie werde ich den Verdacht nicht los, dass du mein Geschreibsel nicht ganz verstanden hast. Ich habe nämlich vorhin fast das gleiche ausgedrückt, nämlich im Zusammenhang mit "end if". ;-) > Mein Gott, jeder, dem ich das erst erklären muss, disqualifiziert sich > als Programmierer eigentlich selber. Er ist nachweislich unfähig, > hinreichend abstrakt-logisch zu denken. Oder halt (aus meiner Sicht viel > schlimmer) aus ideologischen Gründen unwillig dazu... Ich kann jedenfalls sicher konstatieren, dass du dich mit dieser Ausdrucksweise selbst disqualifiziert. Da kommt es dann auch nicht mehr darauf an, ob am Inhalt was dran ist oder nicht, der Beitrag ist unabhängig davon unter aller Sau.
Carl D. schrieb: > Daß sie (die Zeilenumbrüche) in deinem VB.net-Beispiel aber den Part des > "begin" übernehmen, hast sicher verstanden, oder? Natürlich. Was aber ändert das an meiner Bewertung von C?
c-hater schrieb: > Carl D. schrieb: > >> Daß sie (die Zeilenumbrüche) in deinem VB.net-Beispiel aber den Part des >> "begin" übernehmen, hast sicher verstanden, oder? > > Natürlich. Ich dachte dazu müßte man "abstrakt-logisch" denken können.
c-hater schrieb: > Wenn du bei deiner verschissenen schliessenden Klammer > bist, siehst du die öffnende nicht mehr 1) wenn ich eine Klammer aufmache, schreibe ich die schließende SOFORT dahinter. Egal ob geschweift oder rund. Dadurch vergesse ich niemals, eine Klammer zu schließen. Manche Editoren können das auch automatisch. 2) wer bei der schließenden Klammer ein "// end while" setzt, weil die Schleife so lang ist, daß man den Anfang schon wieder vergessen hat, sollte sich mal grundsätzliche Gedanken über seinen Codingstil machen. Wenn schon die Schleife so lang ist, will ich gar nicht erst wissen, wieviel tausend Zeilen die ganze Funktion dann erst haben wird.
A. K. schrieb: > Ich kann jedenfalls sicher konstatieren, dass du dich mit dieser > Ausdrucksweise selbst disqualifiziert Inwiefern? Nur weil dir der Inhalt nicht passt?
c-hater schrieb: > Inwiefern? Nur weil dir der Inhalt nicht passt? Ulkige Entwicklung der Diskussion. Du hast offenbar in aller Aufregung nicht gemerkt, dass ich inhaltlich im Grunde auf deiner Seite bin. Nur nicht so dogmatisch und nicht so aggressiv. ;-) Dass ich mich in C auf mehreren Ebenen recht gut auskenne, impliziert nicht, dass ich davon begeistert wäre. Ich nutze es nur, als Werkzeug, mehr nicht.
:
Bearbeitet durch User
Possetitjel schrieb: > LOGISCHEN Grund. Einfacher lesbar oder verständlicher wäre ja auch ein Grund, nur schwieriger zu entscheiden. Wie bände beispielsweise das Komma?
1 | while *x++, y++; |
Und selbst wenn es ohne Klammer sauberer ist, ... Der Mehraufwand beim lesen bleibt relativ gering.
Nop schrieb: > 2) wer bei der schließenden Klammer ein "// end while" setzt, weil die > Schleife so lang ist, daß man den Anfang schon wieder vergessen hat, > sollte sich mal grundsätzliche Gedanken über seinen Codingstil machen. Da gebe ich dir 100%ig Recht. Nur ist die Realität halt eine andere. Schaue dir einfach mal die öffentlich verfügbaren C-Quelltexte an... Wenn du auch nur halbintelligent bist, kannst du sogar Dienste wie Google das für dich erledigen lassen...
c-hater schrieb: > Nur ist die Realität halt eine andere. > Schaue dir einfach mal die öffentlich verfügbaren C-Quelltexte an... Klar gibt's viel Spaghetti, aber derselbe Stil in Pascal wäre auch nicht übersichtlicher. Ich weiß das, weil ich mit Pascal programmieren gelernt habe und daher weiß, wie schlecht Pascal-Code aussehen kann. :-) Zudem sollte sowas bei professionellem Code im Review auffallen. Es gibt Tools wie SourceMonitor, womit man solche Metriken kostenlos und schnell erstellen kann. Wenn eine Firma das nicht nutzt und auch keine Codereviews macht, sollte sie sich nicht nur Gedanken um den Codingstil ihrer Mitarbeiter machen, sondern noch grundsätzlicher über ihre Entwicklungsprozesse, die Folgekosten technischer Schulden und so weiter.
A. K. schrieb: > Dass ich mich in C auf mehreren Ebenen recht gut auskenne, impliziert > nicht, dass ich davon begeistert wäre. Ich nutze es nur, als Werkzeug, > mehr nicht. Also zumindest dieses Statement könnte auch ich sofort völlig bedenkenlos unterschreiben. Macht uns das schon irgendwie zu Kumpels oder sowas? Ich denke: nein. Weil: wenn du C kannst und die Schwächen von C erkannt hast und nichts dagegen tust, dass sich diese Seuche weiter verbreitet, dann bist du nur ein Opportunist. Ich kann diese Haltung verstehen, irgendwie bin ich ja auch so ein Opportunist (wenn ich mich selber auch eher wegen der eigenen geistigen Gesundheit lieber als "Pragmatiker" bezeichne), der Unterschied ist jedenfalls: ich nehme zumindest in begrenztem Umfang den Kampf gegen die Windmühlen auf (obwohl ich mir natürlich klar ist, dass ich ihn nicht gewinnen kann)...
Diese ganzen Diskussionen ändern nicht ein Iota an den betroffen Programmiersprachen und führt zu absolut nichts. Die wichtigen Programmiersprachen sind an deren Standards gebunden und das alleine zählt, ob gut oder schlecht. Leute mit Erfahrungen können mit den Stärken und Schwächen jener Sprachen umgehen und auch meist damit leben. Perfektion gibt es nicht. Die Probleme aller dieser Sprachen sind hinreichend bekannt und die Berufs Entwickler können und müssen damit leben und damit ihr Geld verdienen. Das umreißt so ziemlich die praktische Situation. Man wählt besser das Übel das man schon kennt. Es wäre besser guten lesbaren Code zu schreiben der auch nach langer Zeit kontextial verständlich ist als sich an subtiler Semantik zu stören. Ich persönlich bin froh, daß ich heutzutage Zugang zu leistungsfähigen Werkzeugen habe, mit den ich meist alle meine Probleme mehr oder weniger zweckmäßig lösen kann. Diese ganzen Streitereien haben in meinen Augen letztlich doch nur überwiegend abstrakten akademischen Charakter für mich. Auch wenn ich mir mit solchen Sprüchen viele Minuspunkte einsammeln werde, finde ich, ist eine gewisse Perspektive nützlich und angesagt. Schönen Abend noch, Gerhard
c-hater schrieb: > Weil: wenn du C kannst und die Schwächen von C erkannt hast und nichts > dagegen tust, dass sich diese Seuche weiter verbreitet, Ach herrje. Religiöses Sendungsbewusstsein geht mir völlig ab. c-hater schrieb: > Oder halt (aus meiner Sicht viel > schlimmer) aus ideologischen Gründen unwillig dazu... c-hater schrieb: > dann bist du nur ein Opportunist. So wirds wohl sein. Ein ideologisch verblendeter Opportunist. ;-)
A. K. schrieb: > c-hater schrieb: >> Weil: wenn du C kannst und die Schwächen von C erkannt >> hast und nichts dagegen tust, dass sich diese Seuche >> weiter verbreitet, > > Ach herrje. Religiöses Sendungsbewusstsein geht mir völlig > ab. Tja... es ist wie immer: Der eine hat das Sendungsbewusstsein, und der andere bewirkt tatsächlich etwas. (Meine Bewunderung und mein Dank sind Dir jedenfalls sicher.)
Dieter F. schrieb: > Possetitjel schrieb: >> das andere aber (manchmal) mit geschweiften, > > Nö, das ist eindeutig. Ich weiss das. Trotzdem rangiert das bei mir unter "syntaktischer Zucker" -- Freiheit, die die Welt nicht braucht. > Merkwürdig für mich ist nur die Praxis, die geschweifte > öffnende Klammer direkt nach dem "Ausdruck" zu schreiben - > das ist für mich unleserlich (daher pinne ich das alles um). Da kannst Du mal sehen :) Ich finde diese Schreibweise nicht nur nicht merkwürdig, sondern sogar völlig natürlich, weil das in Tcl (aus Gründen, die hier zu weit führen würden) syntaktisch so sein muss. Ich bin es also nicht anders gewohnt. Und das Schöne an dieser Schreibweise ist: Sie ist m.W. MISRA-konform. Sie hat den Vorteil, dass kein Fehler in der Blockstruktur entsteht, wenn man nachträglich feststellt, dass statt der einzelnen Anweisung doch zwei Anweisungen notwendig sind -- die jetzt notwendigen Blockklammern steht nämlich schon da und können im Zuge der Ergänzung nicht mehr vergessen werden. > Ich habe anfangs auch erhebliche Probleme mit der "Klammerei" > gehabt [...] Och... das würde ich so nicht sagen. Die Klammerei folgt ja den Prinzipien der strukturierten Programmierung, und die sind, soweit ich das beurteilen kann, in den meisten Sprachen ähnlich implementiert. Ich habe damit keine besonderen Probleme. Ich bin nur weitgehend davon abgekommen, die ganzen Ausnahme- regelungen ("...hier muss kein Semikolon stehen...", "...in diesem Fall können die geschweiften Klammern entfallen...") in Anspruch zu nehmen. Ein Block kommt in geschweifte Klammern und gut.
A. K. schrieb: > Possetitjel schrieb: >> WARUM ist es für den Compiler und/oder für den Programmierer >> wichtig, an dieser Stelle syntaktisch zwischen Ausdrücken >> und Anweisungsblöcken zu unterscheiden? > > Ich verstehe zwar den Fundamentalismus dieser Diskussion nicht, ??? > aber welche syntaktischen Elemente man verwendet, um die > Abgrenzung der Bedingung vom Rest des Codes zu kennzeichnen, > ist keine Frage zwingender Logik, sondern schlicht eine des > persönlichen Geschmacks desjenigen, der die Sprache definiert. Auch -- aber nicht nur. In einer idealen Welt würde derjenige, der die Sprache definiert, auch etwas über Codierungstheorie, natürliche Sprachen und menschliche Wahrnehmung wissen -- und das auch beherzigen. Über eine Sprache, die die irrtümliche Verwendung von "=" statt "==" nicht zuverlässig automatisch erkennen kann, sollte man eigentlich nicht ernsthaft diskutieren müssen. > Die Sache ändert sich ein wenig, wenn man nicht auf der formalen > Syntax rumreitet, sondern den Parser in der Implementierung > betrachtet. In dem Fall kann man den gleichen Parser-Code für > ( ... ) als Teil einer Ausdrucks und als Bedingung von "if" > verwenden. Okay... das beantwortet wenigstens einen Teil meiner Frage. Danke.
Possetitjel schrieb: > Och... das würde ich so nicht sagen. Die Klammerei folgt ja > den Prinzipien der strukturierten Programmierung, und die sind, > soweit ich das beurteilen kann, in den meisten Sprachen ähnlich > implementiert. Ich habe damit keine besonderen Probleme. Algol hat recht viele Sprachen inspiriert. Allerdings finde ich Klammerung mit begin / { ... end / } nur aus mathematisch abstrakter Sicht elegant. Die anweisungsspezifische Klammerung if ... else endif / end if scheint mir letztlich praktischer. Auch deshalb, weil sich nicht überlegen muss, ob Block oder nicht, ob in der gleichen Zeile oder nicht, ... Dazu kommt die oben erwähnte Redundanz und implizite Kommentierung. Wobei "end if" gegenüber "endif" den Vorzug besitzt, mit deutlich weniger Schlüsselworten auszukommen.
:
Bearbeitet durch User
Bernd K. schrieb: > Dieses ganze Anfang und Ende des Blockes nicht mehr > finden oder Klammer verlieren ist ein konstruiertes > Schwachsinnsargument Hmm. Es gibt den Spruch "Man sollte von seinen Mitmenschen nicht immer das Schlechteste annehmen." In diesem Sinne: Du solltest vom c-hater vielleicht nicht gerade das Schlechteste -- nämlich die Umgangsformen eines tollwütigen Hundes -- annehmen. > von Leuten die keine Praxis haben. Ach so. Gelegenheitsprogrammierer sind Luschen, die die Finger vom Programmieren lassen sollen, nicht wahr?! > Sowas passiert in der Praxis nicht. Dumm nur, dass ich neulich stundenlang nach einem Fehler in der Blockstruktur gesucht habe. Nach meiner Erfahrung macht man diese Fehler nicht beim Neuschreiben von Code, sondern beim Refaktorisieren, d.h. beim Ändern. Dort hat man ja das Problem, dass die Einrückung eben zeitweise NICHT stimmt, weil man gerade am Code herumändert.
Hallo, > In einer idealen Welt würde derjenige, der die Sprache definiert, > auch etwas über Codierungstheorie, natürliche Sprachen und > menschliche Wahrnehmung wissen -- und das auch beherzigen. Ich könnte mir vorstellen, das bei der Entwicklung von C vor rund 50 Jahren die Realisierung des Compilers auf den damals verfügbaren Rechnern wichtiger war als Codierungstheorie und Wissen über natürliche Sprachen und menschliche Wahrnehmung. C ist eben eine pragmatische Programmiersprache. rhf
:
Bearbeitet durch User
Possetitjel schrieb: >> Ich verstehe zwar den Fundamentalismus dieser Diskussion nicht, > > ??? Diskussionstil. Für mich sind Programmiersprachen Werkzeuge, die ich nach Bedarf verwende. Keine Elemente harter ideologischer Auseinandersetzung. > In einer idealen Welt würde derjenige, der die Sprache definiert, > auch etwas über Codierungstheorie, natürliche Sprachen und > menschliche Wahrnehmung wissen -- und das auch beherzigen. Ich bin mir nicht so sicher, ob du da bei Dennis Ritchie richtig bist. Ausserdem braucht man eigentlich für alles den idealen Menschen und muss dann leider doch immer mit den realen Menschen auskommen. So wurden Assignops ursprünglich als =+ statt += geschrieben. Das war indes keine wirklich brilliante Idee und wurde rechtzeitig korrigiert. Anderes steckte schon zu tief drin, als man das drüber stolperte. Typnamen wie Schlüsselworte zweiter Klasse zu verwenden wird zum Problem wenn man sie per typedef selber definieren kann. Da typedef erst Jahre später hinzu kam, war das Kind schon im Brunnen und Parser sehen dementsprechend seltsam aus. Stroustrup hat dann in C++ auf diesem Unfug seelenruhig noch einen draufgesetzt. Über die Syntax der Datentypen decke ich lieber den Mantel des Schweigens. Ich habe noch keinen Anfänger erlebt, der die auf Anhieb verstanden hätte.
Roland F. schrieb: > C ist eben eine pragmatische Programmiersprache. In den 60ern gab es Compiler mit einem Dutzend Passes, auf damaligen Mainframes. C entstand auf Minicomputern, weil die leichter verfügbar waren, und sollte da draufpassen ohne schon für "Hello World" stundenlang rumzuackern.
:
Bearbeitet durch User
Hallo, > C entstand auf Minicomputern, weil die leichter verfügbar > waren, und sollte da draufpassen ohne schon für "Hello World" > stundenlang rumzuackern. Genau so ist (war) es. Leider wird das beim beliebten C-Bashing gerne übersehen. rhf
Roland F. schrieb: >> In einer idealen Welt würde derjenige, der die Sprache >> definiert, auch etwas über Codierungstheorie, natürliche >> Sprachen und menschliche Wahrnehmung wissen -- und das >> auch beherzigen. > > Ich könnte mir vorstellen, das bei der Entwicklung von C > vor rund 50 Jahren die Realisierung des Compilers auf > den damals verfügbaren Rechnern wichtiger war als > Codierungstheorie und Wissen über natürliche Sprachen > und menschliche Wahrnehmung. Du sagst es: DAMALS war das wichtiger. Wer HEUTE C lernt und lehrt, muss sich aber an dem orientieren, was heute wichtig ist. Ich kann zwar die Sprache nicht ändern -- aber den Umgang mit ihr.
Roland F. schrieb: > Leider wird das beim beliebten C-Bashing gerne > übersehen. Darum geht es (mir) überhaupt gar nicht. Ich weiss nicht, warum alle Welt so tut, als habe man die Freundin beleidigt, wenn man eine Kritik an der Lieblings-Programmiersprache des Gegenüber äußert. Tatsache ist, dass C unter völlig anderen Bedingungen entstanden ist, als es heute verwendet wird. Darauf geht aber kein mir bekanntes Buch (und auch keine mir bekannte Online-Quelle) ausführlich ein; jeder lehrt C so, als ob man anno Tobak einem absoluten Computer- volltrottel das Programmieren erklären müsste. Ritchie und Co. müssen damals ziemlich viel richtig gemacht haben, wenn C bis heute die Bedeutung hat, die es eben hat -- aber es muss auch erlaubt sein, alles daraufhin abzuklopfen, inwieweit das heute noch relevant ist. Und vieles ist eben nicht mehr relevant; das muss man wissen, um es zu vermeiden, so gut es eben geht.
Possetitjel schrieb: >> Merkwürdig für mich ist nur die Praxis, die geschweifte >> öffnende Klammer direkt nach dem "Ausdruck" zu schreiben - >> das ist für mich unleserlich (daher pinne ich das alles um). > > Da kannst Du mal sehen :) > > Ich finde diese Schreibweise nicht nur nicht merkwürdig, > sondern sogar völlig natürlich, weil das in Tcl (aus Gründen, > die hier zu weit führen würden) syntaktisch so sein muss. > Ich bin es also nicht anders gewohnt. > > Und das Schöne an dieser Schreibweise ist: Sie ist m.W. > MISRA-konform. Da hast Du recht. MISRA macht expliziert keine Stylevorgaben (Ch. 3.2). Possetitjel schrieb: > Ich bin nur weitgehend davon abgekommen, die ganzen Ausnahme- > regelungen ("...hier muss kein Semikolon stehen...", "...in > diesem Fall können die geschweiften Klammern entfallen...") > in Anspruch zu nehmen. Ein Block kommt in geschweifte Klammern > und gut. Wird von MISRA Rule 14.8 auch so gefordert. (Die Angaben beziehen sich auf den 2004er Standard. Den 2012 hab ich nicht hier. Hat sich mWn aber nicht geändert ;) /regards
Possetitjel schrieb: >>> Bei kleinen abgeschlossen Projekten mit ein paar >>> tausend Zeilen mag das egal sein. >> >> Wenn Du bei Enterprise Applications noch über {} oder >> begin end nachdenkst, dann hat Deine Firma ein Problem. > > Nein: Da generell zu wenig über {} oder begin end nachgedacht > wird, haben alle Branchen ein Problem, die Computer einsetzen. Mir ist weder ein C-Programmierer bekannt, der mit {} ein Problem hat, noch ein Pascal Programmierer, der Probleme mit Begin/End hat. Nachgedacht wird da eher darüber dass, zumindest bei größeren Programmsystemen, die Specs meist nicht so eindeutig sind, dass mehrere Teams Codemodule entwickeln können die am Ende auch in allen Fällen sauber miteinander funktionieren. Da fallen nämlich nachher (richtig) hohe Kosten, wenn nicht Schlimmeres, an. Und nicht irgendwelche "Befindlichkeiten" einzelner Diven. /regards
:
Bearbeitet durch User
c-hater schrieb: > Siehe "void*" vs. "void functionname(void)". Dreimal "void", jeweils in > einer völlig anderen Bedeutung. Sowohl semantisch als auch physisch... Also, ein Zeiger, der auf nichts bestimmtes Zeigt, eine Funktion, die nichts zurück gibt und nichts als Parameter übernimmt. Ja, das sind drei völlig verschiedene Sachen :) . Das Hauptproblem ist hierbie enfach die Übersetzung von "void" ins deutsche.
Moment mal, beim durchlesen vom Tread fällt mir gerade auf, dass "C-Hater" eigentlich ein VisualBasic "programmierer" ist. (kicher) Mal davon abgesehen, dass dieser Troll es mal wieder geschafft hat einen Thread zu kapern und in eine schwachsinnige Diskussion über C zu verwandeln :(. Ich fasse mal zusammen: Troll, persönlich Beleidigend, sehr agressiver Tonfall. -> können die Mods da bitte das nächste mal besser aufpassen?
Die mods hätten schon viel früher eingreifen bzw lenken müssen...sobald das gespräch in die falsche richtung abdriftete
Um mal auf die Ausgangsfrage zu kommen: Pascal erscheint so unbeliebt, weil jeder diesbezügliche Thread innerhalb weniger Beiträge von den C-Freaks gekapert wird, die sich dann nur noch über Klammerung und Pointer auslassen. qed
Karl schrieb: > Pascal erscheint so unbeliebt, weil jeder diesbezügliche Thread > innerhalb weniger Beiträge von den C-Freaks gekapert wird, die sich dann > nur noch über Klammerung und Pointer auslassen. qed Andersherum wird ein Schuh draus: Pascal erscheint so unbeliebt, weil praktisch sofort ein Priester oder Missionar vom Range eines "c-hater" erscheint, der lang und ausführlich darlegt, daß er von C keine Ahnung hat, es aber nicht schafft, auch nur einen einzigen Vorteil von Pascal zu beschreiben. Wer A loben will, in dem er nur B herunterputzt, macht irgendwas falsch. So, und zum Abschluss erklärt jetzt bitte noch jemand aus der Pascal-Fraktion, wie man in Pascal eine eigene Funktion/Prozedur wie writeln schreiben kann ... d.h. eine Funktion/Prozedur, der man beliebig viele Argumente übergeben kann.
Karl schrieb: > innerhalb weniger Beiträge von den > C-Freaks gekapert wird ...oder von solchen schrägen Vögeln, die "HASSER" im Namen haben!
Possetitjel schrieb: > Ach so. > Gelegenheitsprogrammierer sind Luschen, die die Finger > vom Programmieren lassen sollen, nicht wahr?! Nein, die sollen einfach weiter machen, mit der Zeit kommt die Übung und die Erfahrung ganz von selbst.
Possetitjel schrieb: > Nach meiner Erfahrung macht man diese Fehler nicht beim > Neuschreiben von Code, sondern beim Refaktorisieren, > d.h. beim Ändern. Dort hat man ja das Problem, dass die > Einrückung eben zeitweise NICHT stimmt, weil man gerade > am Code herumändert. Erstens: schreib die öffnende Klammer oder das begin ans Ende der Zeile, dann kannst Du das schonmal nicht versehentlich weglöschen und die nächste Zeile wird automatisch eingerückt. Zweitens: Benutz eine IDE die einen auch bei Copy/Paste mit den Einrückungen unterstützt. Fertig. > Dort hat man ja das Problem, dass die > Einrückung eben zeitweise NICHT stimmt Die Einrückung hat gefälligst IMMER zu stimmen, spätestens 2 Sekunden nachdem was eingefügt wurde, noch bevor man irgendwas anderes macht! Ich kenne diese Sorte von "Programmierern" die sich einen Dreck um die Einrückungen scheren, da kann ich keine 2 Minuten daneben stehen und deren hilflosem Herumgewürge beim Editieren zuschauen ohne Hautausschlag zu bekommen! Ich hatte schon 2 von denen hier. Man beachte die Vergangenheitsform!
:
Bearbeitet durch User
Rufus Τ. F. schrieb: > So, und zum Abschluss erklärt jetzt bitte noch jemand aus der > Pascal-Fraktion, wie man in Pascal eine eigene Funktion/Prozedur wie > writeln schreiben kann ... d.h. eine Funktion/Prozedur, der man > beliebig viele Argumente übergeben kann. Sowas ähnliches geht mit "Array of const": Gugst du https://www.freepascal.org/docs-html/ref/refsu69.html Ja, es ist nicht Bestandteil vom "Standard" Pascal. Aber Delphi und FreePascal können das...
Rufus Τ. F. schrieb: > auch nur einen einzigen Vorteil von Pascal > zu beschreiben. Der richtige Vorteil meiner Meinung nach (und das ist in der Sprache so angelegt) sind die unglaublich kurzen Kompilierungszeiten. Ich habe das so verstanden, dass die Sprache single-pass Kompilierungen erlaubt.
Unabhängig davon finde ich immer das verlangen bestimmter beispiele kindisch und albern. Ganz offenbar wie auch im ersten post als beispiel..kann man in pascal gebau alles was wichtig ist tun wie in c auch. Wenn interessiert es wenn etwas spezielles nicht geht?!? Sorry aber diese konstrierten probleme sind bescheuert
Nop schrieb: > wer bei der schließenden Klammer ein "// end while" setzt, weil die > Schleife so lang ist, daß man den Anfang schon wieder vergessen hat, > sollte sich mal grundsätzliche Gedanken über seinen Codingstil machen. > Wenn schon die Schleife so lang ist, will ich gar nicht erst wissen, > wieviel tausend Zeilen die ganze Funktion dann erst haben wird. "} // end while" würde ich eh nicht schreiben, denn end sagt ja nichts anderes als das }. Allerdings finde ich } // while(Bedingung){ schon sehr praktisch für den Überblick, wenn Blockanfang und Blockende nicht mehr im selben Blickfeld sind, oder mehrere Blöcke (if, else, for,...) miteinander verschachtelt sind. Ich bevorzuge auch kurze Funktionen, wenn es möglich ist. Aber es gibt auch Aufgaben wie das Erstellen von komplexen Dateien, die sich nicht beliebig in andere Funktionen aufteilen lassen. Funktionen mit ellenlangen Parameterlisten, in denen dann die lokalen Variablen übertragen werden, scheinen mir sowohl in Punkto Überblick als auch Fehleranfälligkeit ein größeres Übel als lange Listen von Anweisungen zu sein.
Karl schrieb: > Ganz offenbar wie auch im ersten post als beispiel..kann man in pascal > gebau alles was wichtig ist tun wie in c auch. Wenn interessiert es > wenn etwas spezielles nicht geht?!? Sorry aber diese konstrierten > probleme sind bescheuert Funktionen mit variabler Anzahl von Argumenten ist mit Sicherheit nichts irgendetwas "spezielles". Das wird in vielen Sprachen ausgiebig genutzt, vor allem bei einer Ausgabe (printf).
dumdidum (nicht angemeldet) schrieb: > Der richtige Vorteil meiner Meinung nach (und das ist in der Sprache so > angelegt) sind die unglaublich kurzen Kompilierungszeiten. Ich habe das > so verstanden, dass die Sprache single-pass Kompilierungen erlaubt. Verglichen mit was? Ist bei C nicht anders. Wobei Passes früher auch eine Frage der Kapazität der Maschine waren, nicht nur der Sprache selbst. Wenn ein Compiler trotz Overlays nicht in 64kB passte, wurden eben 2 Passes daraus. Ein Compiler wird umso schneller, desto weniger Arbeit er sich macht. Man kann C wie Pascal Statement für Statement übersetzen. Statement-übergreifende Optimierung darf man dann aber nicht erwarten. Compiler wie GCC und LLVM sind auf hochoptimierten Code konzipiert. Compiler speziell für Mikrocontroller implementieren das nicht in gleichem Umfang.
dumdidum (nicht angemeldet) schrieb: > Der richtige Vorteil meiner Meinung nach (und das ist in der Sprache so > angelegt) sind die unglaublich kurzen Kompilierungszeiten. Ich habe das > so verstanden, dass die Sprache single-pass Kompilierungen erlaubt. Das kommt von der fast kontextfreien Grammatik. Als Nebeneffekt ist sie nicht nur für Maschinen sondern auch für Menschen unglaublich leicht zu parsen und zu verstehen, daher die gute Lesbarkeit von Pascal-Code im Vergleich zu C++ oder auch C. Der zweite Vorteil ist die relativ hohe Typsicherheit, vor allem im Vergleich zu C. Der dritte Vorteil ist das die Typen hinter dem Bezeichner stehen und nicht davor, auch das erhöht die Lesbarkeit enorm. Das ist meiner Meinung nach die größte und häßlichste Warze die C und alle davon abgeleiteten Sprachen haben. Das mag bei simplen Typen noch nicht so ins Gewicht fallen aber spätestens wenn man Zeiger auf Zeiger hat oder Zeiger auf Funktionen oder dergleichen wird es in der Prefixnotation von C sehr schnell zu einem unglaublich verkrampften Konoten den man spiralförmig(!) von innen nach außen lesen muss. In Pascal schreibt und liest man es einfach von links nach rechts, dort gibt es nichts was man spiralförmig lesen müsste. Moderne Sprachen die sich nicht primär den C-Programmierern und ihren spiralförmig verdrehten und verknoteten Hirnen anbiedern müssen greifen die natürliche links-nach-rechts-Schreibweise zum Glück wieder auf, diese Grammatik hat enorme Vorteile beim Lesen und auch wenn man die Sprache mit optionaler automatischer Typinferenz ausstatten will.
Beitrag #5471575 wurde von einem Moderator gelöscht.
dumdidum (nicht angemeldet) schrieb: > Der richtige Vorteil meiner Meinung nach (und das ist in der Sprache so > angelegt) sind die unglaublich kurzen Kompilierungszeiten Ich habe noch Programmieren gelernt (von Algol aufwärts), als ein Compiler auch mal eine Stunde brauchte oder gleich über Nacht. Bei den heutigen Rechenleistungen spielt das aber keine Rolle mehr, es ist mir ziemlich wurscht, ob ein Programm in 0,1 oder 1 sec compiliert wird. Der normale Programmierer muss ja auch eher selten ein komplettes Windows übersetzen. Georg
TriHexagon schrieb: > Funktionen mit variabler Anzahl von Argumenten ist mit Sicherheit nichts > irgendetwas "spezielles". Weder Pascal noch C kannten die erste Zeit Sprachkonzepte, mit denen sich das in der Sprache selbst implementieren lässt. In C wurde das aber von Anfang an über eine Library abgewickelt, die wusste, wie der Compiler mit Argumenten umgeht (varargs.h). Was auch ausreichte, da C bei Funktionensdeklarationen keine Parameterdeklaration kannte. Das kam erst mit C89 und damit kam dann ein syntaktisches Element, um solche Funktionen zu kennzeichnen. In Pascal gab es keine Möglichkeit, Funktionen mit variabler Anzahl von Argumenten in der Sprache zu formulieren. Weder war es möglich, Funktionen so zu deklarieren, noch liess der strengere Umgang mit Datentypen Hacks wie varargs.h zu. Über heutige Pascal-Varianten habe ich diesbezüglicg keinen Überblick. Wirth verzichtet in seinen späteren Sprachen auch bei sprachimmanenten Funktionen auf eine variable Anzahl Parameter. Damit entfällt das Problem, aber die Formulierung von Textausgabe wird umständlicher. Im Zeitalter von GUIs ist das freilich weniger störend als bei Konsolprogrammen.
:
Bearbeitet durch User
A. K. schrieb: > Verglichen mit was? Ist bei C nicht anders dann halt das modul system und nicht die ewig langen .h Dateien. Zumindest bei mir ist der Eindruck, dass das schneller compiliert (und im Vergleich mit GUI in C++ sehr viel schneller)
Java kompiliert übrigens noch viel schneller als C. Kommt Pascal da dran?
A. K. schrieb: > In C wurde das aber von Anfang an über eine Library abgewickelt, die > wusste, wie der Compiler mit Argumenten umgeht (varargs.h). Eine *.h-Datei ist keine Library, auch wenn die Freunde der Arduino-Fraktion sich alle Mühe geben, das so zu nennen.
dumdidum (nicht angemeldet) schrieb: > dann halt das modul system und nicht die ewig langen .h Dateien. > Zumindest bei mir ist der Eindruck, dass das schneller compiliert (und > im Vergleich mit GUI in C++ sehr viel schneller) Ich bezog mich hauptsächlich auf die implizite Annahme, dass der Unterschied in einem sprachbedingten Zwang zu mehreren Passes läge. Dem ist aber nicht so, auch C lässt sich sequenziell in einem Vorgang übersetzen. Die Problematik langer tief verschachtelter Includes hat die Compilerbauer allerdings durchaus beschäftigt. Wobei das in C noch relativ harmlos ist, verglichen mit C++. Die Konsequenz waren vorkompilierte Includes, in denen ein Teil der Arbeit schon getan war. Die Modularisierung ist in C nicht in der Sprache angelegt, sondern wird voll und ganz dem Programmierer überlassen. Das hat Konsequenzen, die schon früh die Programmierer plagten, besonders bei Projekten mit mehreren Programmierern. Auch Pascal ging eine Modularisierung anfangs völlig ab. Das war dem Charakter der Lehrsprache geschuldet, in der grosse Projekte nicht vorkommen. Spätere davon abgeleitete Sprachen besitzen hingegen Sprachelemente für saubere Moularisierung. Das hat klare Vorteile.
:
Bearbeitet durch User
Rufus Τ. F. schrieb: > Eine *.h-Datei ist keine Library, auch wenn die Freunde der > Arduino-Fraktion sich alle Mühe geben, das so zu nennen. Ok, ich gehöre nicht zu jenen, die bei jeder Gelegenheit über Arduino-User spotten. Macht mich das schon zu einem Freund dieser Szene, über den man folgerichtig spotten sollte? ;-) Aus Sicht der binutils und der einzelnen Files ist ein Include-File keine Library. Aus Sicht von Sprachkonzepten - und da sind wir hier - bilden eine Library und das zugehörige Include-File jedoch eine konzeptionelle Einheit. Es ist dann irrelevant, ob der Code einer Library-Funktion wie getc() einem *.a File steckt (wie fgetc), oder im Include-File selbst.
:
Bearbeitet durch User
Rufus Τ. F. schrieb: > So, und zum Abschluss erklärt jetzt bitte noch jemand aus der > Pascal-Fraktion, wie man in Pascal eine eigene Funktion/Prozedur wie > writeln schreiben kann ... d.h. eine Funktion/Prozedur, der man > beliebig viele Argumente übergeben kann. Das ist mir zu unspeziefisch. Moechtest du: 1) beliebig viele Argumente desselben Typs, oder 2) beliebig viele Argumente unterschiedlichen Typs? Mit Pascal kann ich zwar nicht dienen, aber als konkretes Beispiel mit Rust (ja, ich kann auch C, C++, Python): Der Fall 1) ist recht trivial. Fall 2) aber nicht, denn: Es gibt keine variadischen Funktionen in Rust. Fertig. Das geht nur mit Makros. Aber welche Erkenntnis ziehen wir nun daraus? Ist Rust (oder jede andere Sprache die das nicht hat) deswegen schlecht? Bestimmt nicht. Rust macht, verglichen mit C und C++, vieles richtig und ist mMn sogar das bessere C/C++. Oder C/C++ mit Tuersteher (Compiler) der dir bei jedem noch so kleinen Fehler auf die Finger schlaegt und mit einem Error abbricht. Nicht wie C, wo man mit ganz viel Glueck vielleicht eine Warnung bekommt, wenn man denn die richtigen Warnungen eingeschaltet hat... Nicht falsch verstehen: Ich mag C und C++. Aber die Sprachen haben halt ihre Kanten, die man nicht ausgemertzt bekommt, weil man ja unbedingt abwaertskompatible bleiben will. Natuerlich, auch diesen Gedanken kann ich verstehen, wenn ich mir Python anschaue, wo es das 2.x und das 3.x Lager gibt (scheint ja aber nicht nur ein Pythonproblem zu sein). Und schon sind doch sehr viele Projekte auf eine Pythonversion festgenagelt, weil die Module nicht portiert werden, weil der Maintainer keine Lust drauf hat. Und schon hat man Code um den sich keiner mehr kuemmern will... Wenn ich sehe, das Firmen bei neuen Projekten immernoch Python 2.7 einsetzten (dessen Support schon 2015 enden sollte, aber bis 2020 verlaengert wurde (nur Bugfixes(!)),... naja, nicht meine Baustelle. Doch so schoen C und C++ auch sind (oder auch nicht), es sind keine Sprachen mit denen ich neue Projekte anfangen wuerde. Es gibt sehr gute und vor allem sicherere Sprachen als alternative zu diesen Dinosauriern der Computersteinzeit, z.B. Rust. Warum ich Rust einwerfe? Nur um mal eine andere und neue Sprache zu nennen. Rust hat eben nicht die Altlasten von anno dazumal. Im Gegenteil: Es ist alles sehr durchdacht, inkl. der Toolchain.
Kaj G. schrieb: > Warum ich Rust einwerfe? Nur um mal eine andere und neue > Sprache zu nennen. Rust hat eben nicht die Altlasten von anno > dazumal. Im Gegenteil: Es ist alles sehr durchdacht, inkl. > der Toolchain. Auch Googles Go und Walter Brights D sieht man an, aus Fehlern gelernt zu haben. PS: Von Walter Bright stammt der erste native C++ Compiler.
:
Bearbeitet durch User
Kaj G. schrieb: > Das ist mir zu unspeziefisch. Moechtest du: > 1) beliebig viele Argumente desselben Typs, oder > 2) beliebig viele Argumente unterschiedlichen Typs? Nun, sieh Dir writeln an. Das erlaubt beliebig viele Argumente unterschiedlichen Typs.
Die Frage war, ob es möglich ist, eine Funktion mit variabler Anzahl Argumente mit offiziellen Sprachmitteln selbst zu definieren. In klassischem Pascal geniesst writeln eine Sonderbehandlung durch den Compiler. Der erkennt sie als spezielle Funktion und löst sie in eine Folge einzelner Lib-Aufrufe für die einzelnen Argumente auf (wahrscheinlich). Im klassischen Pascal lässt sich dieses Prinzip nicht auf eigene Funktionen anwenden, das geht nur mit diesen speziellen vom Sprachstandard definierten Funktionen.
:
Bearbeitet durch User
Die Antwort auf die Titelfrage ist ganz einfach: Die Trolls, die gegen Pascal hetzen, haben noch nie (richtig) mit Pascal codiert. => Was der Bauer nicht kennt, isst er nicht!
so einfach schrieb: > Die Trolls, die gegen Pascal hetzen, haben noch nie (richtig) mit Pascal > codiert. Ich würde es eher so formulieren: Sie haben mal vor >10 Jahren mit Turbo Pascal oder UCSD Pascal gearbeitet.
Andreas B. schrieb: > vor >10 Jahren mit Turbo > Pascal eher vor > 25 Jahren Aber so alt sind die gar nicht. Sie labern nur Frasen nach. Ist leider häufig hier in diesem Forum.
so einfach schrieb: > Die Antwort auf die Titelfrage ist ganz einfach: > > Die Trolls, die gegen Pascal hetzen, haben noch nie (richtig) mit Pascal > codiert. Naja, wenn es eine Supersprache wäre, die viele Probleme in der industriellen Softwareentwicklung lösen würde, dann hätte sie sich auch langfristig etwas besser durchgesetzt. Firmen geben doch nicht gerne das 3-8 (oder welcher Faktor auch immer) aus, aus ideologischen Gründen. (Einige schon, aber die Konkurenz sollte dann einen Vorteil haben). Die Frage wäre also was hat C (oder jede andere, erfolgreiche Sprache) was Pascal nicht hat und relevant in der Industrie ist. (Die Antwort ist nicht 'goto' :-) )
Andreas B. schrieb: > Ich würde es eher so formulieren: Sie haben mal vor >10 Jahren mit Turbo > Pascal oder UCSD Pascal gearbeitet. Ob es wohl jemanden gibts, der vor gut 10 Jahren noch UCSD Pascal verwendete? Dessen bessere Tage waren vor fast 40 Jahren. ;-)
Possetitjel schrieb: >> von Leuten die keine Praxis haben. > > Ach so. > Gelegenheitsprogrammierer sind Luschen, die die Finger > vom Programmieren lassen sollen, nicht wahr?! Na na! (räusper) Diesem Satz möchte ich doch gleich zu BEGIN mit aller END schiedenheit streng widersprechen.
1 | if (Blutdruck > 150) |
2 | {
|
3 | void coolDown(); |
4 | |
5 | goto LAZARUS; |
6 | }
|
;-)
Rufus Τ. F. schrieb: > So, und zum Abschluss erklärt jetzt bitte noch jemand aus der > Pascal-Fraktion, wie man in Pascal eine eigene Funktion/Prozedur wie > writeln schreiben kann ... d.h. eine Funktion/Prozedur, der man > beliebig viele Argumente übergeben kann. Ich verstehe das Problem nicht, es ist doch nicht verboten einer Funktion oder Prozedur eine Liste als Parameter zu übergeben?
A. K. schrieb: > > Ob es wohl jemanden gibts, der vor gut 10 Jahren noch UCSD Pascal > verwendete? Dessen bessere Tage waren vor fast 40 Jahren. ;-) Doch, ich. ;-) Ich habe auch nur >10 Jahre (>!) geschrieben weil ich Pascal lange nicht mehr verwendet habe und vor einem Jahr in Form von Lazarus wiederentdeckte. Daher kann ich zur zeitlichen Entwicklung von Pascal nicht viel sagen. Außer daß es momentan auf einen Stand ist, wo man prima mit arbeiten kann. Und das gilt im übrigen genauso für C. Die Vorteile von Lazarus/Pascal sehe ich halt in der einfachen Erstellung einer anspruchsvollen GUI und der Platformunabhängigkiet.
Programmieren ist was für Leute mit zu viel Zeit. Ich geh jetzt in den Biergarten, Wetter passt. Prost..
Guido B. schrieb: > Ich verstehe das Problem nicht, es ist doch nicht verboten einer > Funktion oder Prozedur eine Liste als Parameter zu übergeben? Machst Du das beim Aufruf von writeln auch? Wenn nein, warum nicht?
Andreas B. schrieb: > Die Vorteile von Lazarus/Pascal sehe ich halt in der einfachen > Erstellung einer anspruchsvollen GUI und der Platformunabhängigkiet. Da hier im Forum nicht selten anstatt einem purem "entweder C oder Pascal" ein (mehr oder weniger) sowohl C als auch Pascal (und umgekehrt) zu lesen ist, drängt sich mir folgende Frage auf: Hat schon mal jemand versucht genau diese Vorteile
1 | Pascal/Lazarus IDE: rel. bequem zur GUI kommen, da alles in einer IDE für Win, Linux etc. |
2 | |
3 | C: mehr Freiheiten im Code, kompakter, verbreiteter (Compilerauswahl, massig Beispielcode) |
mit C-Code Modulen zu kombinieren? Ich meine dabei rein praktisch und nicht nur Prinzip bedingt.
Da sehe ich, ehrlich gesagt, nicht die Notwendigkeit. Nenn mal ein praktisches Beispiel.
Andreas B. schrieb: > Da sehe ich, ehrlich gesagt, nicht die Notwendigkeit. > Nenn mal ein praktisches Beispiel. Praktisches Beispiel hab ich jetzt nicht parat. Mein Gedanke war halt, es ist nicht so einfach unter C zu einem GUI-Programm zu kommen, dass auch andere Plattformen einschließt. Für reine Windows Programme geht das gut über die Win32-API (dazu genügt schon Pelles C IDE). Bequemer geht es durch ausweichen auf C#/.NET, bedient aber dann auch nur Windows. 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). Darin liegt doch gerade der Charme für viele gleich alles in einer einzigen IDE mit Lazarus oder Kommerz-Delphi erschlagen zu können. Nur halt mit dem für C-Fans an "kurz Stil Syntax" gewöhnten (deftigen) Nachteil, sich der Wirth'schen Begin/End (und anderen) Gegebenheiten antun zu müssen, was wahrscheinlich eher dazu führt, sich dem aufgeblähten QT-Tanker auszuliefern.
dumdidum (nicht angemeldet) schrieb: > Naja, wenn es eine Supersprache wäre, die viele Probleme in der > industriellen Softwareentwicklung lösen würde, dann hätte sie sich auch > langfristig etwas besser durchgesetzt. Pascal wird in der Softwareentwicklung eingesetzt, vor allem wenn es um sicherheitskritische Anwendungen geht. Du weisst nur nichts davon, weil das nicht die Software ist, die dann bei Github steht oder über die sich die C-Freaks im Forum streiten, wie msn den Code noch unleserlicher hinbekommt.
Karl schrieb: > Pascal wird in der Softwareentwicklung eingesetzt, vor allem wenn es > um sicherheitskritische Anwendungen geht. Mit welchem Compiler?
Gelegenheitsprogrammierer schrieb: > Darin liegt doch gerade der Charme für viele gleich alles in einer > einzigen IDE mit Lazarus oder Kommerz-Delphi erschlagen zu können. Ich sehe es eher getrennt: Wenn ich low Level programmiere, also uC oder sonstiges (Treiber oder Terminalanwendung) dann wähle ich C. Brauche ich SW mit einer GUI, dann Lazarus/Pascal. Dein Problem sehe ich nur, wenn man beides gleichzeitig braucht. Daher die Frage nach einem Beispiel. Wenn man sich natürlich auf eine Programmiersprache beschränkt, ja dann hat man ein Problem.
Gelegenheitsprogrammierer schrieb: > Praktisches Beispiel hab ich jetzt nicht parat. Mein Gedanke war halt, > es ist nicht so einfach unter C zu einem GUI-Programm zu kommen, Was nutzt denn Lazarus unter der Haube? sind alle Libs die in C oder C++ geschrieben wurden. Warum soll ich da nicht gleich das Original nehmen sondern dieses Lazarus mit zusätzlichem draufgeklatschtem weiteren Layer der mehr Probleme macht? > dass > auch andere Plattformen einschließt. Für reine Windows Programme geht > das gut über die Win32-API (dazu genügt schon Pelles C IDE). Bequemer > geht es durch ausweichen auf C#/.NET, bedient aber dann auch nur > Windows. > 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). Lazurus ist dann genauso eine Krücke, Binding zur entsprechenden lib. Wo ist jetzt der Unterschied? Bei Lazarus hat man nen weiteren buggy Layer über eine gängige GUI-Lib drübergeklatscht. Solange das funktioniert ok, meinen Versuchen nach tut es das aber nicht, die Anbindung ist völlig verbuggt. Wenn ich die jeweiligen Originale nutze habe ich weniger Ärger weil die Entwickler das eben mit der jeweiligen Sprache testen in der die Lib entwickelt wurde, in der Pascalecke scheint mir Testen und Qualität bei den Entwicklern sowieso noch nie ein grossen Stellenwert gehabt zu haben, das geht schon mit dem Werkzeug los. Für simple Berechnungstools die hier dauernd preisend genannt werden - mit drei Buttons und ner handvoll Eingabefeldern - funktioniert das vielleicht ohne abzustürzen. Für 'richtige' Programme ist der Krempel viel zu zusammengeschustert. Gibts ne neue Version der darunterliegenden Lib fliesst die nicht sofort in Lazarus ein und ob das ausgibieg getestet wird wage ich zubezweifeln, wenn ich mir die Sourcen dazu anschauen, das läuft alles irgenwie, der Delphifan ist begeistert, sobald man drei Buttons zusammenklicken kann und das durchcompiliert und nicht gleich abstürzt. Lazarus ist ein Hobbyprojekt, so einen Müllhaufen nutzt keiner ernsthaft für grössere Projekte wo man viel Geld reinsteckt. Wie gross ist den die Entwicklerzahl die daran arbeiten wie oft kommen neue Releases, wie schnell werden bugs gefixed,... da stinkt es doch an allen Ecken und Enden gegen die Konkurrenz ab. Delphi und alles was sich daran orientiert ist ein totes Pferd da setzt keiner drauf der noch bei Verstand ist. Irgendwelche Einzelkämpfer die ne Nische damit besetzen sind kein Argument, die findet man in jedem Bereich. Es gibt ja nicht mal nennenswerte OpenSourceprojekte die in Lazarus fabriziert wurden. Alles was da bisher vor mir hatte ähnlich instabiler Schrott. Diesen einen Dateimanger z.B. der damit verbrochen wurde, sieht auch noch grauenhaft aus gerade das sollte doch dann wenigstens mit dem GUI-Zusammenklicktool sauber hinzubekommen sein? Der Delphiclon verspricht viel, hält aber wenig.
Webfehler schrieb: > Bei Lazarus hat man nen weiteren buggy Layer über eine gängige GUI-Lib > drübergeklatscht. Dummschwatz. Meine Programme laufen alle stabil und haben einiges mehr als 3 Buttons.
Webfehler schrieb: > [ jede Menge blinder Hass ] > Der Delphiclon verspricht viel, hält aber wenig. An dieser Bemerkung allein sieht man schon, daß du nicht die Spur einer Ahnung hast.
Dr. Sommer schrieb: > Java kompiliert übrigens noch viel schneller als C. Kommt Pascal da > dran? Java läßt auch das ganze Backend weg. Das darf dann, vernüftige VM vorausgesetzt, jedesmal der JiT-Compiler erledigen.
Andreas B. schrieb: > Dein Problem sehe ich nur, wenn man beides gleichzeitig braucht. Daher > die Frage nach einem Beispiel. Nimm einfach Windows - das ist ganz sicher nicht in Pascal geschrieben, alle tausende API-Funktionen sind in und für C definiert. Und das gilt für die meisten Libraries die man benutzt, z.B. für den Zugriff auf Datenbanken. Windows.h hat mal jemand bei Borland oder Lazarus als Fleissarbeit umgeschrieben in Windows.pas, aber das ist keineswegs vollständig, und wenn was fehlt, muss man halt selbst die Funktionsdefinition anpassen. Das setzt zwingend voraus, dass man ausser Pascal auch C beherrscht. Andreas B. schrieb: > Wenn man sich natürlich auf eine Programmiersprache beschränkt, ja dann > hat man ein Problem. Ausser für ganz einfache Embedded Progrämmchen ist das garnicht möglich. Georg
so einfach schrieb: > Die Antwort auf die Titelfrage ist ganz einfach: > > Die Trolls, die gegen Pascal hetzen, haben noch nie (richtig) mit Pascal > codiert. > > => Was der Bauer nicht kennt, isst er nicht! Manche von denen haben sogar schon auf CP/M Turbopascal-Programme geschrieben, denn TP konnte man irgendwie beschaffen, C-Compiler nicht mal gegen Geld. Nur gab es dann irgendwann auch mehr, und sie haben neues dazugelernt. Sie haben, um bei der Original-Ausdrucksweise zu bleiben, beides gefressen und haben dann ihren Geschmack entscheiden lassen.
Wenn Du auf die Lazarus Seite gehst..steht da.. Written in Pascal for Pascal Unter der Haube von Lazarus ist also Pascal
Andreas B. schrieb: > Ich sehe es eher getrennt: Wenn ich low Level programmiere, also uC oder > sonstiges (Treiber oder Terminalanwendung) dann wähle ich C. Brauche ich > SW mit einer GUI, dann Lazarus/Pascal. Warum? Der Witz ist doch, dass ich die gleiche nRF24 Lib sowohl auf dem uC, der die Sensoren ausliest als auch auf dem Raspi verwenden kann, der die Messwerte empfängt, in der Datenbank ablegt und für die Webseite aufbereitet. Oder dass ich die gleiche Lib mit der Definition der Uart Commands auf dem steuernden PC und auf dem zu steuernden uC habe. Besser gehts doch gar nicht. Ich kann mit Pascal Avr Embedded, Raspi Daemon, Raspi CGI oder FastCGI, Raspi GUI und PC GUI erschlagen.
begin Keine anderes Programmierwerkzeug ruft bei der bloßen Erwähnung seines Namens so viele und so eifrige Widersacher auf den Plan wie Object Pascal und Lazarus. Als ob sie sich irgendwie bedroht fühlen würden von der bloßen Existenz eines so mächtigen Tools. Wenn der Kollege mit Lazarus in zwei Stunden aus dem Handgelenk heraus was vollkommen fehlerfreies und auch noch anständig aussehendes abliefern kann wofür sie sich mit anderen Tools 2 Tage herumgequält hätten ist die Bedrohung (die der eigenen Anschauungen und Vorurteile zumindest) womöglich beängstigend real. Ich interpretiere dieses panische Geschrei das hier immer ausbricht wenn jemand "Lazarus" sagt als höchste Auszeichnung für dieses Tool. Es bestätigt auf lustige Weise was mir (im Gegensatz zu vielen anderen die nun im Nachteil sind und dort feststecken) schon seit 20 Jahren klar war. Und was mich angeht: ich nutze die Macht und lach mir ins Fäustchen. end.
Bernd K. schrieb: > > Ich interpretiere dieses panische Geschrei das hier immer ausbricht wenn > jemand "Lazarus" sagt als höchste Auszeichnung für dieses Tool. Es > bestätigt auf lustige Weise was mir (im Gegensatz zu vielen anderen die > nun im Nachteil sind und dort feststecken) schon seit 20 Jahren klar > war. Manchmal hört man auch einfach nur das eigene Echo. Ich fühle mich nicht vom "biblischen Totegräber" belästigt, den kann man auch einfach nicht benutzen, sondern eher von seinen "Fans", die solche Threads wie diesen hier lostreten und sich dann über Antworten beschweren.
Carl D. schrieb: > Ich fühle mich nicht vom "biblischen Totegräber" belästigt Lazarus ist tot wenn was besseres vorbeikommt. Noch ist nichts am Horizont.
georg schrieb: > aber das ist keineswegs > vollständig, und wenn was fehlt, muss man halt selbst die > Funktionsdefinition anpassen. Zum Beispiel? Ich kann unter Win GUI mit WinApi, Datenbank, Grafik, Uart, Filesystem, Timer, Netzwerk... Mir ist noch nichts untergekommen, was nicht unterstützt wurde. Was nicht heisst, dass es das nicht gibt, dann habe ich es noch nicht gebraucht. Aber mir scheint, Du hast da so ein TP von vor 25 Jahren unter Win3.11 im Kopf.
Bernd K. schrieb: > Carl D. schrieb: >> Ich fühle mich nicht vom "biblischen Totegräber" belästigt > > Lazarus ist tot wenn was besseres vorbeikommt. Noch ist nichts am > Horizont. Man sollte einfach bei der Vergabe von Projektnamen mögliche Assoziationen berücksichtigen. "armer, kranker Mann" oder "der den Herrn von den Toten aufgeweckt hat" könnten unerwünschte Kommentare auf sich ziehen. Und wenn alles tot wäre, wenn jeweils was besseres vorbeikommt, dann gäbe es von jedem nur ein Exemplar. Schein nicht real zu sein.
:
Bearbeitet durch User
Bernd K. schrieb: > der bloßen Existenz eines so mächtigen Tools. Wenn der Kollege mit > Lazarus in zwei Stunden aus dem Handgelenk heraus was vollkommen > fehlerfreies und auch noch anständig aussehendes abliefern kann wofür > sie sich mit anderen Tools 2 Tage herumgequält hätten ist die Bedrohung > (die der eigenen Anschauungen und Vorurteile zumindest) womöglich > beängstigend real. Da ist sie wieder die drei Button-Anwendung mit ner handvoll Eingabefeldern die uns überzeugen soll. Ich bin schwer beeindruckt, ein Programm das in 2h Stunden zusammengestöpselt wurde und die Haare schön hat, äh die GUI schön ist, das wird sicher wahnsinnig komplex sein und Leute überzeugen die an Projekten arbeiten wo mehrere Mannjahre und n*100k€ drinnstecken. Um nen Prototypen zusammenklicken vielleicht, aber selbst dafür brauche ich heute nicht mehr einen Delphiclon, den bringt schon jede GUI-lib mit oder ist gleich in der gängigen IDE integriert. Als Einzelkämpfer kann man auf so einen schlechten Libwrapper mit angeschimmelter Sprache setzen, im professionell Berufsalltag spielt es keine Rolle, weil man da mit mehreren Mann zusammenarbeiten muss da ist die Sprache, Frameworks meist vorgegeben und das sind dann etablierte Technologien nicht so ein geclonter Dinosaurier dem aus allen Ecken schon der Verwesungsgeruch rausdampft. Überhaupt das Personal, finde mal Leute die mit Lazarus Grossprojekte durchgezogen haben, das scheitert ja schon daran, ein unlösbares Henne-Ei-Problem, das man selbst wenn man es lösen könnte immer noch nicht haben will. Nur weil der Delphi/Pascal-Dino noch irgendwie zuckt und Geräusche von sich gibt bedeutet das nicht dass Dinosaurierer heute noch leben und allgegenwärtig sind. Das ist ein Zombie den man endlich pfählen sollte und dann ab damit in ein Loch und viel Erde drüber. Leider taucht er mit den Jahren immer wieder in Foren in Form von Diskussionen als Widergänger auf, ist einfach nicht totzukriegen diese Gammeltechnologie. Am 28.6. hat ein Max S. wieder die Gruft aufgemacht....
Carl D. schrieb: > Man sollte einfach bei der Vergabe von Projektnamen mögliche > Assoziationen berücksichtigen. Du meinst, eine IDE "Finsternis" zu nennen wäre keine so gute Idee?
Webfehler schrieb: > [viel Mist] Man, Dir muss ja ganz schön der Arsch auf Grundeis gehen, bei dem was Du hier so absonderst. Was haben SIE Dir ins Essen getan, dass Du hier so abgehst...
Karl schrieb: > Man, Dir muss ja ganz schön der Arsch auf Grundeis gehen, bei dem was Du > hier so absonderst. Was haben SIE Dir ins Essen getan, dass Du hier so > abgehst... Der Realitycheck für Lazarusjünger ist halt schmerzhaft.
Bernd K. schrieb: > Lazarus ist tot wenn was besseres vorbeikommt. Noch ist nichts am > Horizont. C# hätte so ein "Delphi (Lazarus) - Killer" werden können, da C# eine einfache Erstellung von GUI-Programmen erlaubt, ähnlich wie Lazarus und mit Anders Hejlsberg Architekt von C# ist ja auch die Nähe zu Delphi-Pascal quasi inhärent gegeben. Dumm nur, dass sie eben auf verwalteten IL-Code setzten (warum eigentlich??? 1)), ohne dass es eine Möglichkeit gibt C# auch ganz normal ohne diesen Wasserkopf einzusetzen. C# hätte ansonsten das bessere Delphi werden können für Leute die die geschwätzige Pascal Syntax nicht so recht mögen. 1) Möglicherweise weil MS die Visual BASIC Liebhaber nicht verlieren wollte? Oder weil sie den .NET Unterbau schlicht selber benötigten? Oder weil sie JAVA "kopieren" wollten?
Webfehler schrieb: > geclonter Dinosaurier dem aus allen Ecken > schon der Verwesungsgeruch rausdampft Das ist schon aus dem Grund Blödsinn, weil es eben kein Clon ist. Und was du hier riechst, der "Verwesungsgeruch", das ist der Müll aus deinem Mund, den du über deinen Lieblingsfeind ausschüttest. Muß dir ganz schön Panik einjagen, daß du so dermaßen viel Hass hier auskotzt...
Liebe Güte, das ist ja schlimmer als eine Politikdiskussion!
Hallo,
will mich da mal einmischen.
Webfehler
> Überhaupt das Personal, finde mal
Leute die mit Lazarus Grossprojekte durchgezogen haben, das scheitert ja
schon daran, ein unlösbares Henne-Ei-Problem, das man selbst wenn man es
lösen könnte immer noch nicht haben will.
Ich kenne zwar Lazarus nicht so genau, aber Du würdest dich wundern in
wieviel Großbanken Delphi-Anwendungen laufen und es ein KO-Kriterium
ist, wenn Du in der Banken Scene ein Programm entwickeln willst das
nicht auf Delphi bzw. Objekt-Pascal basiert.
Heute werden noch sehr, sehr viele große und komplexe Programme in
Delphi bzw. Objekt-Pascal entwickelt.
Das ist die eigentliche Zielgruppe von EMBACADERO.
Ciao
A. K. schrieb: > Liebe Güte, das ist ja schlimmer als ... Na ja, bloß weil einer vom Leder zieht ist die gesamte Diskussion nicht gleich so.
Bernd K. schrieb: > Lazarus ist tot wenn was besseres vorbeikommt. Noch ist nichts am > Horizont. Bist du sicher, dass du das Bessere als solches erkennen würdest, wenn es am Horizont auftaucht? Die Frage ist ernst gemeint, denn zumindest mir persönlich geht es so, dass ich so etwas immer erst dann erkenne, wenn es schon Millionen vor mir getan haben. Da frage ich mich dann, wie wohl diese Millionen erkannt haben, dass da etwas Besseres im Anmarsch ist, und wieviel noch Besseres wieder in der Versenkung verschwindet, weil zu wenig Leute darauf aufmerksam werden.
Bernd K. schrieb: > Noch ist nichts am Horizont Wie wär's mit Xojo? Auch super portabel, mit einer intuitiven Anfängerfreundlichen Sprache. Damit kommt man sich sehr schnell ans Ergebnis.
Karl schrieb: > Carl D. schrieb: >> Man sollte einfach bei der Vergabe von Projektnamen mögliche >> Assoziationen berücksichtigen. > > Du meinst, eine IDE "Finsternis" zu nennen wäre keine so gute Idee? Als Gegenpol zum Reich der Sonne ist "Sonnenfinsternis" besser als "Kranker Mann" für etwas, was sein Erfinder nach 5 Jahren mit eine Nachfolger ersetzen zu müssen befand.
Yalu X. schrieb: > Bist du sicher, dass du das Bessere als solches erkennen würdest, wenn > es am Horizont auftaucht? Das Problem fängt schon mit der Definition von "besser" an. Betrachtet man nur die Sprache an sich, oder die gesamte Infrastruktur? Als mir C über den Weg lief (K&R C), fand ich es von der Sprache her keine Erleuchtung, im Vergleich zum mir bereits bekannten Pascal. Aber im Gegensatz zu Pascal fiel uns ein als Ansatz brauchbarer 68000 C-Compiler vor die Füsse, den wir in Eigenarbeit auf ein Selbstbausystem mit Selbstbaubetriebssystem schoben. Und obendrein war noch eine Fundgrube von C Quellcode aus dem Unix-Arsenal verfügbar. Man muss ja nicht alle Räder neu erfinden. War das besser? Nicht im Sinne von Sprachästhetik, sehr wohl aber aus der Praxis heraus. Später verschob sich der Schwerpunkt von der 32-Bit 68000 zum 16-Bit PC (DOS: Lattice C, und 16-Bit Linux für 286). Vom ästhetischen Standpunkt aus war das ein Rückschritt, aber es war da und war leistungsfähiger. > Die Frage ist ernst gemeint, denn zumindest mir persönlich geht es so, > dass ich so etwas immer erst dann erkenne, wenn es schon Millionen vor > mir getan haben. Als C++ auftauchte und in Form des Zortech Compilers verfügbar wurde, dem ersten nativen C++ Compiler, war ich sofort dabei. Wobei das ähnlich ablief. Die Mächtigkeit war mir offenkundig, aber bereits beim ersten Lesen vom Stroustrup standen mir einige Haare zu Berge - zu syntaktischen Strukturen hatte ich mittlerweile etwas Erfahrung gesammelt. Aber es war da, war leistungsfähiger als der Rest, also habe ich es genutzt. Ich habe mir auch diverse andere Sprachen angesehen. Darunter auch Smalltalk, aber was will man mit einer Sprache anfangen, bei der ein fertiges Programm eine Art eingefrorener Memory-Dump aus der Entwicklungsumgebung war, ein "Hello World" in Richtung Megabytes ging. Schlicht unpraktisch. Und so zieht sich dieser Widerspruch zwischen opportunistischer Praxis und ästhetischer Theorie mittlerweile durch 4 Jahrzehnte. Mit APL fing ich nicht an, weil es gut war, sondern weil es in der Schule verfügbar war (und das mir später ein paar Mäuse in Ferienjobs einbrachte), und C finde ich bei Mikrocontrollern nicht wirklich gut, aber praktikabel. Bei Prozessoren wars ja ähnlich. 68000 war zwar "schöner", 386 aber schneller und billiger. Als ich dann in den 80ern zu etwas Papier von einer der ersten ARM-Generationen kam, fiel mir auf, wie man mit viel einfacheren Strukturen die gleiche Leistungsfähigkeit erreichen kann (RISC vs CISC). Beim PC blieb ich trotzdem. Andererseits: Ada kreuzte als nicht handhabbarer Moloch am Horizont auf. Die ersten Compiler galten gegenüber C Compilern als wahre Schlachtschiffe. Chancenlos, zumal das Pentagon als treibende Kraft auch nicht eben lockte. Mittlerweile habe ich den Eindruck, dass das vielleicht der bessere Ansatz im Mikrocontroller-Bereich wäre - immerhin wurde Ada gezielt für embedded Systems entwickelt. Aber der Zug ist nun abgefahren. Die Arbeit, die ich reinstecken müsste, um mit einer bestenfalls halbgaren Entwicklungsumgebung etwas zu machen, kann ich dann auch in die Fehler der Programmierung in C/C++ stecken. Da bin ich zu wenig Ideologe.
:
Bearbeitet durch User
Also hier läuft FPC wunderbar und in Kombination mit GDB macht das richtig Spaß. Sogar sehr alter Code von Turbo Pascal 3.1 lief ohne Anpassungen unter einem neuen Windows das leider keine 16 Bits mehr unterstützt. Für Linux mussten halt die / in \ umgewandelt werden oder anders herum ...
A. K. schrieb: > Yalu X. schrieb: >> Bist du sicher, dass du das Bessere als solches erkennen würdest, wenn >> es am Horizont auftaucht? > > Das Problem fängt schon mit der Definition von "besser" an. Betrachtet > man nur die Sprache an sich, oder die gesamte Infrastruktur? Bezogen auf die Aussage von Bernd Bernd K. schrieb: > Lazarus ist tot wenn was besseres vorbeikommt. Noch ist nichts am > Horizont. und meine Rückfrage definiere ich "das Bessere" als das, weswegen man das bisher Genutzte (bei Bernd wäre das Lazarus und Free Pascal) links liegen lässt, aus welchen Gründen auch immer. Es ist natürlich klar, dass nach dieser Definition jeder etwas anderes als "das Bessere" empfindet. Aber auch dieses persönliche Bessere ist IMHO sehr schwer zu finden, selbst wenn es irgendwo vielleicht schon existiert. Zudem ist die Bewertung mit einem nicht unerheblichen Arbeitsaufwand verbunden, was vermutlich mit einer der Gründe ist, warum sich Programmiersprachen so lange halten, auch wenn sie eigentlich schon überholt sind.
Yalu X. schrieb: > Bezogen auf die Aussage von Bernd > > Bernd K. schrieb: >> Lazarus ist tot wenn was besseres vorbeikommt. Noch ist nichts am >> Horizont. > > und meine Rückfrage definiere ich "das Bessere" als das, weswegen man > das bisher Genutzte (bei Bernd wäre das Lazarus und Free Pascal) links > liegen lässt, aus welchen Gründen auch immer. Das bezieht sich wohl auf die Entwicklung des GUI, ich suche da schon lange nach einem auch nur vergleichbarem Ersatz für Lazarus, habe aber bisher keinen gefunden (ja, ok, Delphi war besser).
Yalu X. schrieb: > Aber auch dieses persönliche Bessere ist IMHO sehr schwer zu finden, > selbst wenn es irgendwo vielleicht schon existiert. Zudem ist die Ob es wirklich besser ist, weiss man oft erst hinterher. > Bewertung mit einem nicht unerheblichen Arbeitsaufwand verbunden, was > vermutlich mit einer der Gründe ist, warum sich Programmiersprachen so > lange halten, auch wenn sie eigentlich schon überholt sind. Natürlich. Es hat etwas von "better the devil you know".
georg schrieb: > Nimm einfach Windows - das ist ganz sicher nicht in Pascal geschrieben, > alle tausende API-Funktionen sind in und für C definiert. ok, das wäre jetzt ein Beispiel wo man GUI und Lowlevelprogrammierung zusammen hat. Aber wer programmiert hier BS? Ich schätze mal <5%. Ich bin immer noch fasziniert darüber wieviele Leute sich hier negativ über Lazarus/Pascal auslassen, die es offensichtlich noch nie in der Hand hatten, geschweige denn damit mal gearbeitet hätten. Und Turbo Pascal lasse ich da nicht gelten. Irgendwie scheint das doch Beißreflexe auszulösen. Was die bemängelten Instabilitäten betrifft: Kann an alten Versionen liegen oder auch an Windows. Keine Ahnung. Die Version 1.6.2 läuft unter Linux jedenfalls absolut stabil. Das betrifft sowohl die IDE als auch die damit erstellte SW. Webfehler schrieb: > Der Realitycheck für Lazarusjünger ist halt schmerzhaft. Und was ist jetzt die Realität? Daß es Pascal Hasser gibt, die noch nie Object Pascal gesehen haben? Stört mich ehrlich gesagt, relativ wenig. Du kannst programmieren mit was Du willst. Meinentwegen auch mit Logo.
hehe.. nach den Meinungen hier im Forum programmieren hier eher 98% Prozent Betriebssysteme :) Deshalb sagte ich ja, ich finde diese Konstruierten Problemstellungen immer witzig. Es werden so lange Beispiele gesucht, für die Pascal nicht gehen könnte ..bis einer jubelnd aufschreit..das er JETZT den eindeutigen Grund kennt haahah Insgesamt scheint es aber so zu sein, das sehr wohl noch eine Menge in Pascal programmieren nur die C Leute lauter schreien und natürlich es auch ein paar mehr von ihnen gibt..Viele sich aber durch die Massenmeinung irren ließen und eher deshalb mit C angefangen haben. 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.# Andere Spprachen wie Go sehe ich weniger als Alternative, da diese nicht oder nicht venünftig auch µC verfügbar ist.' Und ich selber finde es natürlich auch gut, wenn man sowohl am PC als auch am µc die gleiche Sprache nutzen kann, wobei ich durchaus auch C im µc Bereich verstehen und nachvollziehen kann. Im µc Bereich ist C sicher genauso unproblematisch wie Pascal, evtl bietet C hier sogar Vorteile?! aber im PC Bereich kann ich es halt nicht nachvollziehen.wieso man sich das antun sollte
Max S. schrieb: > Im µc Bereich ist C sicher genauso unproblematisch wie Pascal, evtl > bietet C hier sogar Vorteile?! 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. Es muß ja nicht gerade Assember sein (Ausnahme: Tiny10). Ich glaube auch nicht daß Pascalcompiler an die Codeeffizienz von C-compilern drankommen. Ich sehe es ganz pragmatisch: Jedes Werkzeug für seinen geeigneten Zweck. Im übrigen habe ich jahrelang professionell mit VB programmiert: Feuer frei!
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.