Index der verwendeten Programmiersprachen

[pferdefreund]

Wirklich lernen, wie ein Rechner funktioniert und tickt, dazu nehme man am besten S/370 Assembler. Ist nicht ganz so kryptisch wie Intel-Assembler - aber auch hier muss man Register versorgen, Speicher verwalten usw... Ausserdem ist der Befehlssatz überschaubar.

[ViNic]

Woher soll der Lehrer wissen, ob seine Schüler in die Forschung/Entwicklung oder in die Wirtschaft gehen? Okay, statistisch "landen" die Meisten in der Wirtschaft. Daher sollte ein Leherer Grundlagen vermitteln, auf denen alle, auch die Minderbegabten, aufbauen können. Nicht nur kurzlebiges Spezialwissen vermitteln. Bezieht sich auch auf Kopfrechnen, Dreisatz, Prozente und Goethes Faust.

Mit vermitteln von Grundlagen ist es mMn. ausreichend, wenn es in der Schule gemacht wird, da muss man nicht mit OOP oder mit bestimmten Entwurfsmustern rumschlagen. Wobei Design und Logik zu trennen, also warum es zumindest wichtig ist, sollte hier auch bereits geübt werden. Das es auch mit einer "toten" Sprache wie TurboPascal gelehrt wird, ist für mich auch absolut in Ordnung. Es geht eben um Grundlagen und ich habe bisher keine Sprache gefunden, welches die Grundsachen wirklich unterschiedlich behandelt. Die Syntax kann sich unterscheiden, aber die Grundlagen an sich sind meist immer die selben. In der Berufsausbildung/Studium kann man auf dieses Wissen dann einfacher zugreifen, weil man bereits früher schon Erfahrungen gesammelt hat.

[BenutzerGa4gooPh]

@Vinic: Mit dem Studium oder Berufsausbildung, also spezialisiert auf den künftigen Beruf "zukunftsfähige" oder besser ausgedrückt, gebräuchliche Sprachen zu lehren, gebe ich dir vollkommen Recht. (Normales Abitur sehe ich noch als Allgemeinbildung mit Goethe und Faust. Mag aber persönliche Geschmackssache sein.) Und wenn ich einsehe, schreibe ich nicht viel.

Wirklich lernen, wie ein Rechner funktioniert und tickt, dazu nehme man am besten S/370 Assembler. Ist nicht ganz so kryptisch wie Intel-Assembler - aber auch hier muss man Register versorgen, Speicher verwalten usw... Ausserdem ist der Befehlssatz überschaubar.

Das ist ein interessanter Einwurf - ich mag Extremwerte wegen der Kontrolle eigener Theorien (früher waren es auch Programme): Assembler wurde uns per Zilog Z80 (DDR U880?) mit diversen, umschaltbaren Speicher-Registern gelehrt, Assembler hatte mir Jahre später bei einem heute nicht mehr hergestelltem Microcontroller geholfen - sowie für aktuelle (?) Simatic S7 (SPS-Steuerung, AWL ist ähnlich Assembler).
Vlt. ist gut, bei solchen Erfahrungs-Diskussionen "Extremfälle" zu betrachten?! Assembler (zu) sehr abhängig von Hardware, als dass "reine Lehre" sinnvoll ist? Nach eigenen Erfahrungen jedoch nicht! Schreibe ruhig mehr, mich interessiert es!

Außerdem interessiert mich die Zukunft(?) von stinknormalem C. (Turbo Pascal wurde leider entsorgt.) Es gibt nicht nur Websites und dahinter liegende Shopping-Datenbanken, embedded devices und Maschinen brauchen heutzutage auch mal etwas Software. Neben CNC und SPS. Früher gab es Dreher, Bohrer, Arbeiter, Selbständige, Freiberufler, Bauern, wenig und nicht arbeitende Herren und Damen...

[wanne]

Mit vermitteln von Grundlagen ist es mMn. ausreichend, wenn es in der Schule gemacht wird, da muss man nicht mit OOP oder mit bestimmten Entwurfsmustern rumschlagen. Wobei Design und Logik zu trennen, also warum es zumindest wichtig ist, sollte hier auch bereits geübt werden. Das es auch mit einer "toten" Sprache wie TurboPascal gelehrt wird, ist für mich auch absolut in Ordnung. Es geht eben um Grundlagen und ich habe bisher keine Sprache gefunden, welches die Grundsachen wirklich unterschiedlich behandelt.

Grundlage ist OOP. Deswegen steht die auch in den meisten Lehrpänen. (Im übrigen gibt es Schulen, die das auch ganz ohne Programmiersprache machn. (Übe den Unsinn darf man sich gerne auch streiten:-) ))
TurboPascal vermittelt vor allem Spagetti Code zu produzieren, den man dann mit viel Gewalt in fast jede Sprache portieren kann. Aber vernünftig eine moderne Sprache wie Haskell, Erlang, Scala oder Clojure oder auch Java C++ und lua kannst du deswegen nicht. Da ist das eher hinderlich.
Viele UNIs lassen absichtlich zum lernen DrRecord lernen die rein iteratives Programmieren aktiv unterbinden damit wirklich Konzepte gelernt werden statt mit der Holzhammermethode jedes Problem zu Lösen. Auch Java versucht sowas (weit weniger erfolgreich) zu unterbinden.

Zu Fortran: Bei uns im HPC-Bereich gibt es viele libs, die sowohl in C wie auch Frotran77 geschrieben sind (und dann je die selben Bindings für C anbieten ). Da sind die Frotran77 eigentlich immer etwas schneller. Und das obwohl in C Compiler deutlich mehr Optimierungsarbeit geflossen ist. Nimmt man ältere Compiler oder das gcc, ist das nochmal deutlicher.
Aus der Sicht schade, dass das auch unter den Physikern ausstirbt. (Der eigentliche Code der bei uns läuft ist da fast immer C.)
Grauenhaft sind vor allem die Python Programme, die da immer mehr auftauchen. Die legen oft für Aufgaben den halben Cluster lahm, wo ich wetten würde, dass das wenn es mal jemand sauber schreiben würde auf meinem PC laufen würde. Nur so ein Gefühl. Aber mir kommts so vor als wären bei den Pythonprogrammieren irgend wie alle Volltrottel vereint.

Auf der anderen Seite spielt das für 99% der Programme kaum ne rolle. Und schneller fertig ist man in Python, bash oder Perl halt schon. (Habe vor kurzem mal das selbe Programm zuerst in bash und dann in Perl geschrien. Perl Programm lief ein paar Sekunden. Bash war auch nach Stunden noch nicht fertig. Die unperformance der Bash ist schon beeindruckend.) Dafür funktioniert das Programm dann typischerweise genau in einer Umgebung für ein Problem.

Viel wichtiger ist die Wartbarkeit und mit mehreren Leuten an einem Projekt ist C++ IMHO echt immer noch ungeschlagen. Du guckst dir die Doxygen generierte Doku an, und wenn der Programmierer nicht ganz geschlamt hat, kapierst du auch bei riesigen Projekten nach ein paar Tagen um was es geht.

[heisenberg]

Die unperformance der Bash ist schon beeindruckend.

Na. Ich würde sagen da gibt es gerade im Bashbereich auch schon Welten des Unterschiedes, je nach dem wie performant und effizient man gelernt hat damit zu programmieren - da hat man auch schnell mal ein paar Tausend? Millionen? Prozesse erzeugt bei grösseren Programmen. Aber für grössere Programme würde ich selbst nur unter Androhung von Folter in Bash programmieren wollen. Im übrigen sind für mich Bash <-> HPC schon Positionen, wie Sie nicht weiter voneinander entfernt sein können.

[ViNic]

Grundlage ist OOP. Deswegen steht die auch in den meisten Lehrpänen. (Im übrigen gibt es Schulen, die das auch ganz ohne Programmiersprache machn. (Übe den Unsinn darf man sich gerne auch streiten:-) ))

Naja... ich spreche von einer stinknormalen Schule und nicht von einer Uni. Normal bekommst du wohl keinen IT-Lehrer mit Java Kenntnissen und Schüler die sich für Programmieren großartig interessieren. Auch ist der Stoff für Schüler wohl auch so komplex genug.Also ich kenne zumindest keine Schule die eines oder anderes anbietet. Das es in der Uni anders ist, bezweifle ich nicht. Bis jetzt habe ich nur die Erfahrung gemacht, das jeder sich selbst das Programmieren beibringen muss. Habe ich so gemacht und mir wurde auch so empfohlen. Entweder man hat Spaß daran oder auch nicht.

[tobo]

TurboPascal vermittelt vor allem Spagetti Code zu produzieren, den man dann mit viel Gewalt in fast jede Sprache portieren kann.

Wenn du unter Spagetti Code das verstehst, was man darunter landläufig versteht, dann ist deine Aussage nicht nur falsch, sondern das Gegenteil davon ist richtig. Davon ab, Turbo Pascal war die Entwicklungsumgebung, Pascal war die Sprache; heute Object Pascal. Pascal wurde als Lehrsprache entwickelt, um den Leuten eine klar strukturierte und typisierte Sprache anzubieten und damit das Grundverständnis fürs Programmieren zu fürdern. Und viel Gewalt bei der Portierung ist ebenfalls nicht nötig - ich würde wetten, dass selbst Nichtprogrammierer einen einfachen Pascal-Text verstehen können. Und da du ja sebst die Wartbarkeit anführst, die Lesbarkeit des Textes ist der Schlüssel zur Wartbarkeit!?

Und was das Sterbedatum von TurboPascal angeht, längst durch Object Pascal ersetzt. Will man unter Windows native GUI-Anwendungen erstellen, dann findet sich in meinen Augen nichts besseres, schnelleres oder sichereres, als das mit Delphi zu erledigen.

[wanne]

ich würde wetten, dass selbst Nichtprogrammierer einen einfachen Pascal-Text verstehen können.

Nichtprogrammierer eher nicht. Aber ja einfache Programme versteht jeder den man etwa eine Woche eingewiesen hat. Komplexere Programme bestenfalls der Entwickler selbst.
Das gilt allerdings genauso für die hochgelobten funktionalen. Solange es bei einem Einzeiler bleibt ist das noch einfacher zu verstehen als Basic. Aber wehe das wird 5 stellig. Keine Chance mehr.

Will man unter Windows native GUI-Anwendungen erstellen, dann findet sich in meinen Augen nichts besseres, schnelleres oder sichereres, als das mit Delphi zu erledigen.

Und viel Gewalt bei der Portierung ist ebenfalls nicht nötig

Und damit hast du alle Vorurteile zu Pascal entwicklern bestätigt. Haben einen Grauenhaften Stiel zu programmieren und wenden es auf alles an was ihnen vor die Füße gewofen wird.
Hier ganz einfach: Übersetz das mal in Scheme oder Haskell und frag einen der das wirklich macht, was er davon hält:

Code: Alles auswählen

while n < 100 do
   n := n + 1;

Und schon ein C Programmierer würde das so nicht machen.

[ViNic]

Hier ganz einfach: Übersetz das mal in Scheme oder Haskell und frag einen der das wirklich macht, was er davon hält:

Code: Alles auswählen

while n < 100 do
   n := n + 1;

Und schon ein C Programmierer würde das so nicht machen.

Und die Auflösung? Wie würde das der C Programmierer machen?

[tobo]

Und damit hast du alle Vorurteile zu Pascal entwicklern bestätigt. Haben einen Grauenhaften Stiel zu programmieren und wenden es auf alles an was ihnen vor die Füße gewofen wird.

Mir ist nicht ganz klar, wie du das aus meinen Sätzen schlussfolgern kannst?! Davon ab ist der Programmierstil nicht durch die Sprache vorgegeben. Und dann noch eine Sache, die gegen deine These der Gewaltportierung spricht: Verwendet man heutzutage Pseudocode, um anderen Programmierern einen Algorithmus oder ähnliches aufzuzeigen, dann ist dieser häufig sehr nah an Pascal angelehnt, wenn nicht sogar in Pascal geschrieben

Code: Alles auswählen

while n < 100 do
   n := n + 1;

Und schon ein C Programmierer würde das so nicht machen.

Und was genau stört dich daran jetzt? Abgrenzung von n<100 durch Klammern, Schleifenrumpf in begin/end, Leerschleife? Wenn Du als Delphi-Programmier das so hinschreibst und damit schlechten Programmierstil offenbarst, wer genau hindert mich dann daran, das als C-Programmierer - mit angepasster Syntax - ebenfalls so hinzuschreiben und damit die Summe aller C-Programmierer zu verunglimpfen?

[owl102]

ich würde wetten, dass selbst Nichtprogrammierer einen einfachen Pascal-Text verstehen können.

Glaubst du das ernsthaft? Dann zeige mal deinen Pascal-Quelltext deiner Frau oder deinem Vater oder Mutter oder...

Für mich ist auch nicht entscheidend, wie gut ein Quelltext für Nicht-Programmierer verständlich ist, sondern, wie gut ein Quelltext für Programmierer verständlich ist.

Will man unter Windows native GUI-Anwendungen erstellen, dann findet sich in meinen Augen nichts besseres, schnelleres oder sichereres, als das mit Delphi zu erledigen.

Warum müssen die unbedingt nativ sein? Mir würde da zum Beispiel C# oder Java einfallen. Beides hätte auch den Vorteil, daß man nicht auf einen Closed-Source-Compiler einer einzelnen Firma angewiesen ist. (Nein, Lazarus ist zwar nett, aber mehr nicht. Insbesondere kann man nicht einfach aktuelle Delphi-Anwendungen unter Lazarus übersetzen.)

Python+Qt möchte ich auch noch in den Ring werfen.

Und überhaupt würde ich mich weigern, die Frage nach der Programmiersprache so pauschal zu bewerten, ich sehe das lieber in dem Kontext der konkreten Anforderungen und der konkret zur Verfügung stehenden Entwicklern. Und auch in dem Kontext, ob es eine kommerzielle Anwendung werden soll oder nicht, denn bei einer solchen verbietet sich IMHO Delphi. Man hatte ja an Kylix gesehen, wie schnell so ein einsamer Sonderweg in einer Sackgasse enden kann.

[SGibbi]

Boah eY, hat das eine Dynamik entwickkelt. Ich komme kaum mit dem Lesen nach.

Nee, ich bin Elektroingenieur, ich bin hardwarenah, und die einzig wirkliche Programmiersprache für mich ist Assembler. Nee, ehrlich, habe Heute noch irgendwo eine Diskette mit Wordstar aus CP/M Zeiten rumliegen. Wie heißt noch der kompatible Linux Editor ? Pico ? Wordstar hat keinen "Verfall", denn man kann da noch ASCII Escape Strings eintragen und sich eigene Druckertreiber definieren. Auf meinem DR-DOS Rechner läuft derzeit allerdings der Ravitz Editor, der kann das auch.

Solange die Rechner die von Neumann Architektur haben, ist Assembler immer ähnlich, und schneller als Assembler ist nur noch optimierter Assembler. Ich bin kein Lehrer mehr, und in Fachkunde Elektro gibt es anderes, was die Schüler nötiger erlernnen müssen als Programmieren (naja, vielleicht SPS, aber dafür gibt es "Programmgeneratoren").

C frißt 30% bis 50%. Rechenleistung. Gegenüber Assembler wäre unser Linux Rechner ziemlich genau doppelt so schnell, würden wir Assemblieren. Und die Abweichungen von CPU zu CPU kann man sich Heute in jedem besseren Programmiereditor als Makro definieren.

Trotzdem wird C so schnell nicht totzukriegen sein. Die Portierbarkeit ist beispielhaft, man braucht als Programmierer keine Hardware Kenntnisse, und moderne Hardware hat Leistung. Mein 12 Jahre alter Pentium spielt mir unter Linux die tanzende Madonna als Video in Bild und Ton. Was will ich mehr ?

Pascal war DIE Sprache der DOS Shareware Szene. Am Ende war es der Bettvorleger für C. Schade. Wäre Pascal Code portierbar geworden, allein die vielen DOS Games, kein Mensch würde mehr das langweilige Windoze nehmen. Turbo Pascal unter DOS war allerdings ziemlich schnell. Die schnellste CAD in DOS war Geddy CAD, habe das noch Heute auf der Platte, ich kenne kein vergleichbares Linux Äquivalent, und das war 100% Pascal Code.

Ich habe Fortran wirklich zu hassen gelernt. Sofern es ein physikalisches Limit bei der Hardware gibt, und es wird wie überall irgendwann eines kommen, werden wir früher oder später auf Assembler müssen. Solange zig verschieden Hardware Systeme konkurrieren, wird C schon wegen der Portierbarkeit nicht totzukriegen sein. Und zumindest so lange wird es unser geliebtes Linux geben.

Von Skriptsprachen, sei es Bash oder was auch immer z.B. an Java im Webbrowser läuft, halte ich nicht viel. Soo einfach zu programmieren ist es auch nicht, und Performance, naja, unter aller Sau. Es zu erlernen verlorene Zeit. Wer Heute (ersthaft) publiziert, nimmt (bereits) PDF und nicht (mehr) HTML.

Ich meine, wenn wir schon bei Fortran IV und bei Pascal sind, was ist denn eigentlich aus den ganzen BASIC Programmierern geworden, das war einst wesentlich populärer zumindest als Fortran. Sind die Helden der 1980er schon alle tot ? Wann endlich kommt Basic für Linux (würde es nicht nehmen, aber dann wären alle C-64 Spiele auf Linux verfügbar)

Okay, ich halts Maul, Tschüss und bis dann !

[tobo]

Glaubst du das ernsthaft? Dann zeige mal deinen Pascal-Quelltext deiner Frau oder deinem Vater oder Mutter oder...

Wohl gemerkt einfacher Quelltext, erheblich kleiner als 5-stellig! Und wenn es nicht verstanden wird, dann auch nicht in einer der anderen bislang genannten Sprachen.

Für mich ist auch nicht entscheidend, wie gut ein Quelltext für Nicht-Programmierer verständlich ist, sondern, wie gut ein Quelltext für Programmierer verständlich ist.

Klar. Wie breits gesagt, Pseudocode wird im Allgemeinen ähnlich zur Pascalsyntax aufgeschrieben, so dass andere Proggrammierer (egal welche Sprache) es nachvollziehen können. Sollte ein ziemlich gutes Argument sein!?

Beides hätte auch den Vorteil, daß man nicht auf einen Closed-Source-Compiler einer einzelnen Firma angewiesen ist.

Das ist Diskussionsstoff, der kein Ende findet. Genauso könnte man sich fragen, wieso die Firmen Closed-Source-Betriebssysteme verwenden und sich in die Abhängigkeit einer einzelnen Firma begeben!? Support? Versteh' mich nicht falsch, ich bin kein Fan von Closed Source bzw. Delphi, wohl aber finde ich die Sprache Object Pascal gut.

(Nein, Lazarus ist zwar nett, aber mehr nicht. Insbesondere kann man nicht einfach aktuelle Delphi-Anwendungen unter Lazarus übersetzen.)

Natürlich ist das nicht einfach, das liegt aber weniger an Lazarus sondern an Free Pascal, welches schlicht noch nicht alle Sprachkonstrukte nachgebildet hat. Allerdings sind da beide Projekte meiner Meinung nach auf einem ziemlich guten Weg.

Und überhaupt würde ich mich weigern, die Frage nach der Programmiersprache so pauschal zu bewerten, ich sehe das lieber in dem Kontext der konkreten Anforderungen und der konkret zur Verfügung stehenden Entwicklern.

Stimmt schon, war meinerseits auch nur als Einwand auf die Abgesänge von TurboPascal gedacht. Mir ging es hauptsächlich um die "pauschale" Kritik an Pascal als Lehrsprache, mit Argumenten, die ich nicht nachvollziehen kann.

Und auch in dem Kontext, ob es eine kommerzielle Anwendung werden soll oder nicht, denn bei einer solchen verbietet sich IMHO Delphi. Man hatte ja an Kylix gesehen, wie schnell so ein einsamer Sonderweg in einer Sackgasse enden kann.

Den Gedankensprung verstehe ich jetzt nicht?! Das Projekt eingestellt werden können ist immer klar. Kylix ist ja auch nicht nativ gelaufen - ich kann mir nicht vorstellen, dass da jemand ernsthaft große Hoffnungen drauf gesetzt hat. Davon ab, wie oft wurde Delphi jetzt verkauft - 6, 7 mal? Vor kurzem gab es schon wieder einen Käufer. Die wenigsten OpenSource-Projekte dürften solch eine Fluktuation an der Spitze vertragen!?

[hikaru]

Will man unter Windows native GUI-Anwendungen erstellen, dann findet sich in meinen Augen nichts besseres, schnelleres oder sichereres, als das mit Delphi zu erledigen.

Mag sein, aber ich finde Delphi als Lehrsprache trügerisch.
Als Pascal-Abkömmling sieht es erstmal nach einem guten Kandidaten dafür aus, aber meiner Beobachtung nach tendierten Schüler die TP kannten dazu, sich in Delphi eine schicke Oberfläche zusammenzuklicken und dann den automatisch generierten Delphi-Rumpfcode mit prozeduralem Code zu füllen wie sie es aus TP kannten.
Das Ergebnis funktionierte wunderbar, aber die Leute meinten dann plötzlich, sie könnten OOP, denn Delphi ist ja schließlich objektorientiert. Müssen sie dann in einer anderen Sprache selbst mit Objekten hantieren, dann fallen sie aus allen Wolken.

[tobo]

Mag sein, aber ich finde Delphi als Lehrsprache trügerisch.
Als Pascal-Abkömmling sieht es erstmal nach einem guten Kandidaten dafür aus, aber meiner Beobachtung nach tendierten Schüler die TP kannten dazu, sich in Delphi eine schicke Oberfläche zusammenzuklicken und dann den automatisch generierten Delphi-Rumpfcode mit prozeduralem Code zu füllen wie sie es aus TP kannten.
Das Ergebnis funktionierte wunderbar, aber die Leute meinten dann plötzlich, sie könnten OOP, denn Delphi ist ja schließlich objektorientiert. Müssen sie dann in einer anderen Sprache selbst mit Objekten hantieren, dann fallen sie aus allen Wolken.

Man muss nicht in Delphi objektorientiert Programmieren, aber man kann. Wenn ich mir darin eine Oberfläche zusammenklicke (was ich nicht müsste), dann ist das streng genommen schon objektorientiert, ja. Will ich allerdings als Neuling der Programmierung Ergebnisse auf einem Monitor sehen und sehe dann eine Konsole mit Buchstaben vor mir, dann schreckt das 90% ab. Ich denke diesen Kompromiss kann man machen. Man gibt ihnen eine grafische Oberfläche und lehrt die Sprach- und grundsätzlichen Programmierelemente dann anhand prozeduraler Programmierung. Denn OOP ist für einen Neueinsteiger in meinen Augen völliger Unsinn. Zunächst mal glaube ich, dass ein Großteil der Leute, die von sich behaupten OOP zu programmieren, nur prozedural programmieren unter Verwendung von Klassen. Da wird hier mal eine Klasse erzeugt, da mal eine abgeleitet - nur weil ich Klassen verwende ist das nicht objektorientiert gedacht. Hohe Bindung, lose Kopplung, Austauschbarkeit, Delegation, Entwurfsmuster - Fremdwörter. Da muss man sich nur mal ein paar Quelltexte durch die Bank anschauen, dann sieht man direkt, wie nah das an der Wahrheit ist. Es kommt dann ja nicht nur die Komplexität der OOP auf einen Neuling zu - die selbst viele Profis in ihrer Eigenart überhaupt nicht begreifen, aber "anwenden" - das eigentliche Handwerk ist ja auch noch nicht vermittelt. Und wenn ich in der Schule Pascal lernen soll, dann muss das absolut keine kastrierte Delphi-Trial mit den bekannten Einschränkungen sein, sondern darf gerne das kostenlose Lazarus sein. Will ich programmieren lernen, dann ist das absolut ausreichend und für jede Schule ohne Lizenzen machbar.

[dufty2]

Sehe das eher pragmatisch:
Lernte in der Schule Englisch und nicht Suaheli.
Suaheli ist bestimmt auch nicht "schlechter" als Englisch,
aber die Wahrscheinlichkeit, im späteren (Berufs-)Leben es nutzen zu können/müssen, ist wohl geringer.
Deshalb für Java (und mit Abstrichen vielleicht python) und gegen FORTRAN66 oder Assembler (oder mit Abstrichen Delphi)

Und bezüglich formaler Verifikation ("no bugs instead of less bugs") sticht keine hervor
(wobei OO nicht verifiziert werden kann, so mein letzter Wissensstand).

[Lord_Carlos]

Von Skriptsprachen, sei es Bash oder was auch immer z.B. an Java im Webbrowser läuft, halte ich nicht viel. Soo einfach zu programmieren ist es auch nicht, und Performance, naja, unter aller Sau. Es zu erlernen verlorene Zeit.

Du meinst javascript?
Oder wirklich das tote java plugin fuer browser?

[owl102]

Wie breits gesagt, Pseudocode wird im Allgemeinen ähnlich zur Pascalsyntax aufgeschrieben

Wie definierst du "im Allgemeinen"? Ich behaupte mal, daß dies im allgemeinen nicht mehr so ist, diese Zeiten sind IMHO lange vorbei. Pseudo-Code sehe ich heutzutage entweder als Diagramm, mit Pfeilen, oder ähnlich zu Java.

Genauso könnte man sich fragen, wieso die Firmen Closed-Source-Betriebssysteme verwenden und sich in die Abhängigkeit einer einzelnen Firma begeben!?

Dies ändert nichts an der Tatsache, daß diese Abhängigkeit keine positive, sondern eine negative Eigenschaft ist. Es muß also ausreichend Gründe geben, sich doch in die Abhängigkeit zu begeben. Bei Delphi sehe ich die nicht, es sei denn, es ist bereits (zu) viel Codebasis in Delphi vorhanden.

Kylix ist ja auch nicht nativ gelaufen - ich kann mir nicht vorstellen, dass da jemand ernsthaft große Hoffnungen drauf gesetzt hat.

Natürlich gab es Firmen, die Neuentwicklungen in CLX statt VCL getätigt hatten (selbst wenn sie an Linux als Zielplattform kein primäres Interesse hatten), schließlich wurde CLX von Borland als "Zukunft" beworben.

[wanne]

Na. Ich würde sagen da gibt es gerade im Bashbereich auch schon Welten des Unterschiedes, je nach dem wie performant und effizient man gelernt hat damit zu programmieren - da hat man auch schnell mal ein paar Tausend? Millionen? Prozesse erzeugt bei grösseren Programmen.

Hatte darauf geachtet, dass ich ausschließlich befehle nutze, die in der bash integriert sind.

Aber für grössere Programme würde ich selbst nur unter Androhung von Folter in Bash programmieren wollen.

War eine einzelne Schleife mit vielleicht 4 Zeilen.

Im übrigen sind für mich Bash <-> HPC schon Positionen, wie Sie nicht weiter voneinander entfernt sein können.

In dem Fall gieng es um was für mich zu hause. Trotzdem ist die Bash da für Verwaltungsaufgaben natürlich groß.

Da muss man sich nur mal ein paar Quelltexte durch die Bank anschauen, dann sieht man direkt, wie nah das an der Wahrheit ist.

Also gerade wenn du dir Android Apps anguckst ist das praktisch nur Spezialisierung und sonst gar nichts. Prozedural ist da absolut gar nichts. Die ich suche mir was, was für mich ähnlich klingt und dann auf Stackoverflow, wie ich das nach meinem Wunsch anpasse führt zwar ganz und gar nicht zu besserem Code aber so ist mittlerweile eine ganze Generation weg vom prozeduralen Programmieren gekommen. Die machen nur noch OOP. Bei C++ sieht das noch etwas anders aus. Da laufen aber auch immer noch verdammt viele rum, die mal mit Pascal angefangen haben. Und die programmieren halt ausschließlich Prozedural und sind vollständig resistent gegen jegliches dazulernen.

Klar. Wie breits gesagt, Pseudocode wird im Allgemeinen ähnlich zur Pascalsyntax aufgeschrieben, so dass andere Proggrammierer (egal welche Sprache) es nachvollziehen können. Sollte ein ziemlich gutes Argument sein!?

NEIN! Genau das Gegenteil ist der Fall. Es gibt viele Konstrukte wie OOP die für sich komplex zu verstehen sind aber geübten Lesern Sachen deutlich vereinfachen. Eine Sprache weitestgehend ohne Grammatik (Klingonisch) ist deutlich einfacher zu lernen sinnvoll komplexere Sachverhalte zu formulieren geht aber eben extrem schwer.
Bronze schmieden ist deutlich einfacher als alle anderen Metallverarbeitungen. Kannst du als Workshop auf dem Mittelaltermarkt anbieten und wurde schon 5000 Jahre vor Edelstahl hergestellt. Stattdessen nutzen wir für Anwendungszwecke wo früher Bronze genutzt wurde heute typischerweise Edelstahl dessen Herstellung und Verarbeitungsverfahren ganze Bibliotheken füllen. Nicht weil es einfacher zu erlernen ist, sondern weil es für darauf spezialisierte Menschengruppen schneller billiger und in größeren Mengen funktioniert. Dabei ist dann das Ergebnis auch noch deutlich robuster.

Ansonsten ist der eher an basic angelehnt weil halt jeder mal basic gesehen hat, und die Leute es deswegen für einfach hielten. Und schwankt nach und nach Richtung C und Java weil das halt häufig ist. Und wäre haskell die verbreitetste Sprache sähe Pseudocode garantiert gaaanz anders aus.
Das einzig wirklich ohne Vorkenntnisse verständliche ist das "mit Pfeilen":

C frißt 30% bis 50%. Rechenleistung. Gegenüber Assembler wäre unser Linux Rechner ziemlich genau doppelt so schnell, würden wir Assemblieren.

Das ist falsch. Es gab mal einen Wettbewerb für IA64 Assembler und C Programmierer gegen den Intel Compiler. Die allermeisten Assembelten deutlich langsamer. Du musst schon verdammt viel über derzeitige Prozessoren wissen (Wie große sind die Caches, wie lange die Pipelines), und verdammt gut sein, das alles einzubauen um einen guten Compiler outzuperformen. IA64 ist da natürlich noch besonders böse, aber dein mit Makros Plattformunabhängig gemachter Code ist garantiert auch auf einem modernen x86 deutlich langsamer als das was ein besserer Compiler produziert.

Und was genau stört dich daran jetzt? … Wenn Du als Delphi-Programmier das so hinschreibst und damit schlechten Programmierstil offenbarst

Stören tut mich daran erstmals nichts. Das ist das Beispiel aus der Wikipedia für Pascal Code. So unüblich kann das nicht sein. In C haben sie aber tatsächlich was ähnliches drin. Die wollen halt auch allgemeinverständlich sein.
Aber in anderen Sprachen nimmst du andere Konstrukte. Und genau das ist das Problem mit Leuten die als erstes Delphi lernen. Sie machen genau das:

Abgrenzung von n<100 durch Klammern, Schleifenrumpf in begin/end, Leerschleife?

Und dann ist es eben gar kein schöner Programmierstil. Du nutzt eben nicht, was die Sprache dir bietet, sondern das was sie in Pascal gelernt haben, und denken am ende jede Programmiersprache würde so funktionieren.
Z.B. Könnte man sowas in C so lösen:

Code: Alles auswählen

while(i++-100);

Über die Lesbarkeit von sowas kann man sich streiten, aber ein geübter C-Programmierer wird dir die Sinnlosigkeit des Codes gesehen haben, bevor du die 2 Zeilen Pascal überhaupt gelesen hast.
In Scheme wird das im übrigen richtig lustig:
Man könnte auch da irgend wie sowas schreiben:

Code: Alles auswählen

(define (loop n)
  (if (< n 100)
      (loop (+ n 1)
      0)))

Aber hier würde dir dann halt echt jeder das Programm links und rechts um die Ohren hauen weil schleifen in Scheme halt eigentlich nichts zu suchen haben.

[hikaru]

Eine Sprache weitestgehend ohne Grammatik (Klingonisch) ist deutlich einfacher zu lernen

Wenn du dich tatsächlich mal mit der klingonischen Sprache beschäftigt hättest, dann wüsstest du, dass sie eine sehr ausgefeilte Grammatik hat - mit allen dazugehörenden Vor- und Nachteilen.
Ohne Kenntnisse der Grammatik wirst du dich auf Klingonisch selbst mit Vokabelkenntnissen kaum verständlich machen können, denn der Ansatz schlecht Englisch sprechender Deutsch-Muttersprachler, einfach die Vokabeln auszutauschen, führt nicht zu einem schlechten aber verständlichen Klingonisch, sondern bestenfalls zu Kauderwelsch, schlimmstenfalls zu einer formal halbwegs korrekten aber sinnentstellten Aussage.

[DeletedUserReAsG]

Von Skriptsprachen, sei es Bash oder was auch immer z.B. an Java im Webbrowser läuft, halte ich nicht viel. Soo einfach zu programmieren ist es auch nicht, und Performance, naja, unter aller Sau. Es zu erlernen verlorene Zeit. Wer Heute (ersthaft) publiziert, nimmt (bereits) PDF und nicht (mehr) HTML.

Oh je, da wird ja wieder einiges durcheinandergeworfen und verquirlt. Scriptsprachen verlorene Zeit? Erstaunlich in einer Zeit, in der die meisten Sachen mit Scriptsprachen realisiert werden. Die wenigsten Webandwendungen sind für die Serverhardware kompiliert, in aller Regel laufen da … Scriptsprachen. Viele lokale Anwendungen werden mittlerweile zu einem großen Teil mittels Scriptsprachen realisiert – bis hin zu Spielen, etc. (Lua hat da den Ruf, ziemlich schnell zu sein, und kommt in erstaunlich vielen Spielen zum Einsatz). Heutzutage steht in den meisten Fällen Rechenleistung und Speicherplatz in ausreichendem Maß zur Verfügung, während die Software am besten gestern schon fertig sein muss. Und du willst da mit C oder gar Assembler ankommen, weil Scriptsprachen verlorene Zeit sind? Nun ja ….

Java im Webbrowser ist, bis auf ganz wenige Spezialfälle, heute gar nicht mehr anzutreffen. Und so wirklich langsam ist Java auch nicht, eine Scriptsprache ist es schon gar nicht.

Und HTML vs. PDF? Beide sind uralt (HTML erschien 1989, PDF wurde 1993 vorgestellt, das zugrundeliegende Postscript gibt es schon erheblich länger) – und beide sind (natürlich in aktuellen Versionen) heute noch genauso im Einsatz, wie früher™ – jedes dort, wofür es gemacht wurde. HTML wird und wurde naturgemäß nicht für exakt festgelegte Darstellung und als Druckvorstufe verwendet, PDF wird und wurde nicht für Webseiten genommen. Ich frage mich daher, worauf du hinaus möchtest.

[heisenberg]

...bash ist total langsam...

Unter den o. g. Bedingungen ist der Aussage dann nichts mehr hinzuzufügen.

[novalix]

Manchmal gewinnt man den Eindruck objekt-orientiertes Programmieren sei mit dem Gebrauch von Java gleich zu setzen. Dabei ist Java einfach nur eine Sprache, die kaum ein anderes Paradigma als eben OOP zulässt. Das ist aber aus Grundlagensicht heraus eine Einschränkung. Das OOP-Paradigma ist leistungsstark. Es kann aber eben auch nur, was es kann.
Wo wir schon bei Scheme waren: Anfang der siebziger haben Guy Steele und Gerald Sussman gezeigt, dass lexical closures Prozeduren erlauben, die mit einem jeweiligen Status in ihrer Umgebung verbunden sind. Das sind wie Alan Kaye - der Entwickler von Smalltalk und "Erfinder" des Begriffs "object oriented" - äußerte die "building blocks", die Bausteine, einer höheren Abstraktion.
In diesem Sinne ist Oblektorientierung ein mögliches Paradigma auf Basis funktionaler Komponenten.
Lisp ist die multiparadigmatische Programmiersprache. Ginge es also darum, die Konzepte des Programmierens grundlegend und umfangreich zu vermitteln, wäre Lisp der geeignete Kandidat.
Aber darum geht es offensichtlich nicht.

[wanne]

In diesem Sinne ist Oblektorientierung ein mögliches Paradigma auf Basis funktionaler Komponenten.

Als jemand der mit OOP groß geworden ist, fand ich auch dass Scheme geradezu dazu anregt objektorientiert zu programmieren. – Sehr zum Ärgernis meiner Tutoren im ersten Semester an der UNI. „Das kommt später“.
Ich glaube es ist schon nicht ganz dumm erstmal. Sprachen zu lernen, die nur ein Paradigma zulassen um genau dieses zu vermitteln sonst nutzt man ja doch nur ausgewählte teile der Sprache.
Man ist ja leider ziemlich schnell Turingvollständig und kann auch mit einem Paradigma alles machen.

Wenn man dann alles kann, kann man auf sprachen wie C++ umsteigen die einem alles mögliche erlauben. Solche Sprachen sind aber nichts für anfänger.
Wie war das „With great power comes great responsibility“

Scheme als vergleichsweise primitive Sprache die Paradigmen gut zeigen kann git zumindest an europäischen UNIs schon als DIE Sprache um gut programmieren zu lernen.
Bei uns gab es viele Features erst nach und nach. Auch wenn es uns (vor allem die, die schon besser als die Tutoren programmieren konnten) wahnsinnig generft hat, ist das glaube ich keine dumme Idee zu Lehren.

[SGibbi]

Hallo Lord_Carlos, Hallo Niemand,

Mit Skriptsprache meinte ich "Interpretersprache", also Sprachen, die (normalerweise) nicht oder nur teilweise compiliert werden. Beispiele wären in der Tat Java Script oder Bash oder z.B. das gute alte "Batch" von GOD (Good old Dos). Daß die Aussage grenzwertig ist, weiß ich, so konnte man früher z.B. BASIC Programme wahlweise am Interpreter ablaufen lassen oder compilieren.

Ansonsten hat sich der Thread mittlerweile anderen Themen zugewandt, lassen wir es mal dabei, sich jetzt eine Klobberei um Java zu gönnen (wozu) bringt den Thread nicht voran. Zudem ich von Delphi keine Ahnung habe daher nicht mitreden kann.

Das einzige, was ich im Moment noch ernsthaft "programmiere" ist HPGL. Das ist eine Druckersprache, die mir aus DOS Textmodus schöne Formatierungen ermöglicht. Und vielleicht etwas SPS, das gehört zum Beruf, also hardwarenah.