Vergleich höherer Programmiersprachen

[Tanja_michel]

Hallo alle zusammen,ich muss eine Präsentation zum Thema:Vergleich höherer Programmiersprachen machen und da bräuchte ich noch etwas Hilfe,vielleicht kann mir einer von euch ein paar links dazu schicken oder so
Explizit geht es um die Benutzeroberfläche beider Generationen(von der textbasierten zu grafisch orientierten) mit den jeweiligen Konsequenzen
Außerdem benötige ich noch die Veränderung der grafischen Darstellung von Programmen von beiden generationen
ich hab schon alles möglcihe bei google eingegeben aber finde einfach nichts.....
könnt ihr mit bitte helfen?
Liebe Grüße
Tanja

[Corpsman]

Na da hast dir ja was eingebrockt ;)

Wenn du via Google nichts gefunden hast kann ich dir leider nicht helfen. Aber generell dürfte es schwer sein Programmiersprachen an sich zu vergleichen, denn Laut Churcher These sind sie alle Gleich wenn Turingmächtig. Du dürftest höchstens Unterschiede auf spezielle Anwedungen und Aufgaben rausarbeiten können.

Oder auf Benutzerfreundlichkeit, "Brainfuck" als Sprache ist bestimmt ein Gutes Negativbeispiel.

[DGL-luke]

Hallo,

es gibt keine grafisch orientierten Programmiersprachen.

C wird per Text geschrieben, Delphi, PHP, Java, C#...

Was du meinst ist eventuell die IDE. Aber ide IDE ist nur ein Hilfsmittel.

Was du eventuell auch meine könntest, ist der Vergleich der Benutzeroberflächen der erstellten Programme. Aber auch daran kann man nicht die Sprachen messen.

Bei Wikipedia findest du gute Zusammenfassungen zu den Programmiersprachen.

[3_of_8]

Doch, es gibt graphische Programmiersprachen. Aber das meist Spielzeug, zum Beispiel Kara der Käfer oder so ein Ding, bei dem jeder Pixel-Farbwert einen Befehl bedeutet...

[MikeS]

Ich kenne LabVIEW als grafische Programmiersprache. Wird von National Instruments entwickelt und vertrieben. Viel Spaß noch bei Deiner Arbeit. :-)

[Tanja_michel]

ich meinte die Benutzeroberfläche eines Programms,also wie ichs verstanden habe,musste man früher einen kompletten text einfach eintippen auf ein leeren Bildschirm,heute bzw. bei einigen Programmen ist es ja nun anders,so zb. bei delphi.Bei welchen Programmen musste man tippen und bei welchen nicht?was war an den Programmen noch anders als bei delphi z.b ?Welche Konsequenzen sind daraus zu schließen wenn man nur objekte zusammen klickt wie bei Delphi?
bei der grafischen darstellung meinte ich z.b Struktogramme oder schleifen etc.wie stellt man diese in den Sprachen der 3.Generation dar?
HILFE!!!!!!!!!!!!!!!!!!!!!!!

[Corpsman]

Doch es gibt Graphische Programmiersprachen

S7 z.b.

Ich Denke sie meint mit Graphisch auch diese Programmiersprachen wo man mit so Bubbles das Programm zusammenklickt.

[cruiser]

Hm... mit Delphi kann man durchaus noch Konsolenanwendungen "auf den leeren Bildschirm" schreiben. Für wirklich kleine Sachen ist das manchmal sogar nützlicher und schlanker. Zum anderen ist es oft mit zusammenklicken von Objekten nicht getan, weil die Datenhaltung und -verarbeitung trotz allem meist noch von Hand gemacht werden muss oder sollte. Und da unterscheiden sich die "alten" Sprachen kaum von den "neuen".

[Dezipaitor]

Da darfste die Progsprache Ada net vergessen.Ganz tolle und sichere Sprache - so ähnlich wie Delphi. Oberfläche zu proggen ist nur seh umständlich zu machen. Aber Weltraumraketen, wo Ada verwendet wird, oder US Army Sicherheitssdinge, brauchen das nicht so großartig.

[OG Karotte]

Also hier (Softwaregeschichte der 1950er und 60er Jahre) steht ein wenig was über die "frühen" Programmiersprachen
und hier steht doch 'ne ganze Menge zu "aktuellen" Programmiersprachen inkl. ihrer Entstehungsgeschichte.

Was ich allerdings auch nicht gefunden habe ist ein direkter und objektiver Vergleich.

Hier ist wohl ein wenig Arbeit angesagt:

- Heraussuchen der aktuellen Hochsprachen (und anhand der Geschichte jeder einzelnen lässt sich schon mal der eine oder andere Punkt zwischen Konsole (Text basiert) und GUI herausarbeiten)
- Auflistung der grundlegenden Möglichkeiten (inkl. Plattform-Abhängigkeiten)
- Bedienerfreundlichkeit (Umfang der IDE)
- Abhängigkeiten von (externen) Bibliotheken um die erstellte Anwendung lauffähig zu bekommen

Grundsätzlich gilt aber wohl:

Alle Hochsprachen können über einen einfachen Texteditor "bedient" werden. Nur die IDE's vereinfachen die Programmerstellung um einiges (Fehlersuche, Projektverwaltung, Codevervollständigung usw.).

[Christian Seehase]

Moin Tanja,

da ich mal davon ausgehe, dass Du zumindest die graphisch orientierten Sprachen kennst, könnte es Dir vielleicht weiterhelfen, wenn Du Dir selber mal ein Bild von den textorientieren machst.
Hierzu könntest Du Dir mal Turbo Pascal/C/C++ anschauen, die Du hier herunterladen kannst.
Inwieweit die allerdings unter aktuellen Windowsversionen noch zum Laufen zu bekommen sind, weiss ich auch nicht.

[turboPASCAL]

Zitat:

... aktuellen Windowsversionen noch zum Laufen zu bekommen sind, weiss ich auch nicht.

Alle Windowsversionen ausgenommen Vista (nod tested :stupid: ).

Man darf an dieser Stelle vill noch einwerfen das es nicht nur Kompieler gibt sondern auch Interpreter
zB. die früheren Basic Versionen. Ich kann mich noch gut an QW-BASIC und Q-BASIC erinnern bei denen,
besonders im Falle von QWBASIC man einfach seinen Text auf einen "leeren" Bild schrieb.

[inherited]

In der Wikipedia gibt es in den Artikeln über höhere Sprachen einen Bereich indem jeweils Vor- und Nachteile aufgelistet werden. Vielleicht ist das ja was für dich.

[Dezipaitor]

und in der Bibilothek in deiner Nähe, wirst du auch noch viel finden :D
Also ich meine jetzt die Gebäude mit den vielen Büchern.

Ne wirklich. Guck mal in allgemeine Informatikbücher rein. Da sind meistens gut beschriebene Progsprachenübersichten drin.

[Tanja_michel]

Zitat:

Zitat von turboPASCAL

Zitat:

... aktuellen Windowsversionen noch zum Laufen zu bekommen sind, weiss ich auch nicht.

Man darf an dieser Stelle vill noch einwerfen das es nicht nur Kompieler gibt sondern auch Interpreter
zB. die früheren Basic Versionen. Ich kann mich noch gut an QW-BASIC und Q-BASIC erinnern bei denen,
besonders im Falle von QWBASIC man einfach seinen Text auf einen "leeren" Bild schrieb.

kennt einer konkret zwei sprachen die man gut vergleichen kann?an denen man Unterschiede gut erkennen kann?Compiler und Interpreter gibt es bieden Generationen zugleich somit ist das eine Gemeinsamkeit :)

was meinst du mit allgemeinen Informatikbüchern?Kennst du eins mit namen?

[Christian Seehase]

Moin Tanja,

ich gehe mal davon aus, dass Du mit Benutzeroberfläche in erster Linie einmal die der mit der Entwicklungsumgebung erstellten Anwendungen meinst.
Da bietet es sich beispielsweise an, Turbo Pascal (DOS) und Delphi zu vergleichen.

[Nuclear-Ping]

Hallo Tanja,

mir ist immernoch nicht ganz klar, was du willst und suchst.

Alle "grafischen" Programmiersprachen (in deinem Verständnis wahrscheinlich die Entwicklungsumgebungen (IDEs) der Sprachen) sind nur sowas wie aufgesetzte "Hilfestellungen" weiterentwickelter Grundsprachen. Zum Beispiel bei Basic -> Visual Basic, Pascal -> Delphi / Lazarus / Kylix / Turbo Delphi, C/C++ -> Borland C++ Builder / Visual Studio, etc. Zu Pascal sagt man zum Beispiel heute gern auch "Objekt Pascal".

Diese "Hilfestellungen" nehmen dem Entwickler im Grunde nur die Arbeit ab, Benutzerelemente (Eingabefelder, Buttons, Listen, ...) durch API-Befehle zu erzeugen, zu verwalten und wieder freizugeben. Allerdings kann man solche Elemente auch gänzlich ohne eine IDE ("grafische Oberfläche") erstellen. Stichworte zu diesem Thema sind "Assarbad", "nonVCL". Links: http://www.michael-puff.de/dirindex....API_Tutorials/ oder http://www.assarbad.net/ Allerdings ist hier der Aufwand recht hoch und es wird auch ein tieferes Verständnis der API-, Fenster- und Message-Mechanik von Windows vorrausgesetzt bzw. benötigt. Vorteil davon sind jedoch schnelle schlanke Anwendungen mit einem gewissen "Nerd"-Style. :P

Das Thema kann man auch noch weiter zurückdrehen und sagen, dass Turbo Pascal und Turbo C(++) auch schon IDEs hatten, die hier dem Programmierer allerdings nur die Verwaltung des Compilers und Linkers abgenommen haben. Früher musste man nämlich in der Tat noch seinen Code in einen Texteditor schreiben, die Datei speichern, ihn verlassen und den Compiler / Linker per Hand aufrufen und Meldungen (wie Fehler, fehlende Dateien, ...) notieren, den Editor wieder starten, etc ... ;)

Wenn du "Hochsprachen" miteinander vergleichen willst, wirst du zu keinem großen Ergebnis kommen, ausser dass sie (wie hier schon angesprochen) im Grunde alle gleich sind und sich nur durch Anwendungsgebiete minimal unterscheiden.
Delphi und VB zum Beispiel unterscheiden sich nur dadurch, dass die von VB erzeugten Exe-Dateien (glaube durch Bytecode) interpretiert werden, während Delphi echten Binärcode erzeugt.
C(++) unterscheidet sich zu VB und Delphi, dass damit die Erzeugung systemnaher Anwendungen (Treiber zum Beispiel) möglich ist, während das mit VB garnicht und mit Delphi nur durch üble Kopfstände zu bewerkstelligen ist.

Turbo Pascal und C sind im übrigen auch "Hochsprachen", die "Assembler" abstrahieren. Weitere Informationen findest du in Wiki / Google.

[Tanja_michel]

das klingt alles auf jedenfall sehr hilfreich und wird mir bestimmt einige Anregungen zur Bearbeitung geben,vielen dank
ich hab da aber noch eine Frage und zwar welche programmtechnischen Konsequenzen es hat wenn man nur textbasiert programmiert oder Objakte zusammen klickt?
Wie sieht es denn aus mit der veränderung bei der grafischen Darstellung von Programmen aus?Hat man Struktogramme z.B bei C++ anders dargestellt als bei SQL?Gibt es bei SQL überhaupt Schleifen?und wie werden diese im vergleich zu Dritten Generation aufgezeichnet?

[Nuclear-Ping]

Eine Anwendung zusammenklicken kann man nicht. Irgendwoher muss der Code kommen, der sagt was wie wann zu tun ist. Du kannst eine Oberfläche zusammenklicken, die aber nix weiter tut ausser nur gut oder schlecht auszusehen. Alle Aktionen die ausgeführt werden, wie zum Beispiel der Klick auf einen Button oder das Füllen einer Liste mit Inhalten, müssen in der Regel programmiert werden (oder sie wurden von jemand anderem programmiert und werden nur eingebunden).

SQL ist keine Programmiersprache, genausowenig wie HTML (wenn wir schon beim Thema sind :P). SQL ist eine Datenbank-Abfragesprache, "Structured Query Language". HTML hingegen ist eine Formatierungssprache ("HyperText Markup Language").

[alzaimar]

Zitat:

Zitat von Nuclear-Ping

SQL ist eine Datenbank-Abfragesprache, "Structured Query Language".

Stimmt so nicht. Man kann nicht nur Daten abfragen, sondern auch Daten schreiben, Datenbanken, Tabellen etc. basteln sowie Nutzer anlegen und die Nutzerrechte sehr detailiert verwalten. So gut wie jede SQL-Implementierung erweitert die Sprache um Konstrukte zur Programmierung (IF THEN, WHILE, PROCEDURE etc.)

Aber eine 'richtige' Programmiersprache wird es damit auch nicht. Immerhin, einen kleinen Compiler kann man damit basteln (Geek-Projekt).

[DGL-luke]

Hallo,

ich würd hier gern nochmal meine Meinung zum besten geben, dass es wenig bis gar keinen Sinn macht, programmiersprachen danach zu unterscheiden, ob sie Benutzeroberflächen erzeugen können oder die erzeugten programme nur im textmodus laufen. Denn das ist absolut nicht sprachabhängig. Jede Sprache, deren Kompilate modulbasiert sind und mit denen man z.B. auf "C-kompatible" DLLs zugreifen kann, kann unter z.B. Windows eine grafische Benutzeroberfläche implementieren.
Und anders wird das ja auch nicht gemacht.

Natürlich kann man dann "richtige" Programmiersprachen und so Zusammenklick-Sachen wie sie erwähnt wurden (mea culpa! mea maxima culpa!) vergleichen. Aber auch das halte ich nicht für sinnvoll, da zweitere wohl einfach viel weniger zahlreich sind.

Was man aber sehr wohl vergleichen könnte, wäre die Arbeit unter textbasierten Systemen - schreiben, kompilieren, linken, konfigurieren, testen, und von vorne - mit der heutigen (RAD-)IDE-Integration, mit so Sachen wie Refactoring, Modellunterstützung, "Fix and Continue"-Debugging, Remote-Debugging usw. usf.

Das hat alles Vor- und Nachteile.

[Tanja_michel]

Zitat:

Zitat von DGL-luke

Hallo,

Was man aber sehr wohl vergleichen könnte, wäre die Arbeit unter textbasierten Systemen - schreiben, kompilieren, linken, konfigurieren, testen, und von vorne - mit der heutigen (RAD-)IDE-Integration, mit so Sachen wie Refactoring, Modellunterstützung, "Fix and Continue"-Debugging, Remote-Debugging usw. usf.

Das hat alles Vor- und Nachteile.

Genau das habe ich gemeint!Welche Vor und Nachteile hat es denn?Und wo kann ich solche finden? Wie sieht es mit der darstellung von Programmen aus?kann mir da einer weiterhelfen?es ist echt wichtig(ist meine Abipräsi)
Tanja

[DMW]

Zitat:

Zitat von Tanja_michel

Genau das habe ich gemeint!Welche Vor und Nachteile hat es denn?Und wo kann ich solche finden?

Eigentlich hat das hier

Zitat:

Zitat von DGL-luke

so Sachen wie Refactoring, Modellunterstützung, "Fix and Continue"-Debugging, Remote-Debugging usw. usf.

keine Nachteile (höchstens Verweichlichung :p). Du kannst es allerdings sprachbezogen betrachten - für syntaktisch einfachere Sprachen wie Java, Delphi, C# etc. gibt es solcherlei Dinge zuhauf, für C++ z.B., welches viel mehr syntaktische Möglichkeiten bietet, aber dementsprechend auch viel schwerer zu parsen ist, sind Refactorings, Modeling, "Fix and continue" etc. sehr selten zu finden. Bei der Sprachwahl muß man also abwägen - eine einfachere, aber nicht so mächtige Sprache und jede Menge Produktivitätstools oder eine komplexe, an Möglichkeiten reichere Sprache, dafür aber Verzicht auf solche Tools.

[Hansa]

Zitat:

Zitat von Tanja_michel

Welche Konsequenzen sind daraus zu schließen wenn man nur objekte zusammen klickt wie bei Delphi?

Dass sich da keiner drüber beschwert ? :???: :lol: Na gut, mal ein paar Anregungen. Außer eventuell ein paar Exoten sind alle Programmmiersprachen textbasiert. In der Theorie kann man mit jedem Editor ein Delphi-Programm schreiben. Das gilt auch für andere Sprachen. Und das "Geklicke" hat nichts mit Programmiersprachen zu tun, sondern eher mit den IDEs. Lege ich mir einen Button auf eine Form, dann kann ich den zwar hin und her ziehen, aber was dahinter steckt, das ist die Änderung der Koordinaten in der dazugehörigen DFM-Datei (Text). Klicke ich den Button nun an, dann habe ich doch nur ein Grundgerüst und nicht mehr. Ab da hört nun das Geklicke aber auf und ich muss meinen Quelltext schreiben. Und zwar wirklich von Hand. :zwinker:

Soll es wirklich um Programmiersprachen gehen, dann würde ich das am Beispiel von sagen wir mal Delphi und C präsentieren. Zwei Programme, die dasselbe tun. Am Quelltext wird selbst ein Blinder mit Krückstock den Unterschied sehen. IMHO musst Du etwas über die Syntax schreiben und die IDEs vielleicht am Rande trotzdem erwähnen.

[Tanja_michel]

Zitat:

Zitat von Hansa

Zitat:

Zitat von Tanja_michel

Welche Konsequenzen sind daraus zu schließen wenn man nur objekte zusammen klickt wie bei Delphi?

Dass sich da keiner drüber beschwert ? :???: :lol: Na gut, mal ein paar Anregungen. Außer eventuell ein paar Exoten sind alle Programmmiersprachen textbasiert. In der Theorie kann man mit jedem Editor ein Delphi-Programm schreiben. Das gilt auch für andere Sprachen. Und das "Geklicke" hat nichts mit Programmiersprachen zu tun, sondern eher mit den IDEs. Lege ich mir einen Button auf eine Form, dann kann ich den zwar hin und her ziehen, aber was dahinter steckt, das ist die Änderung der Koordinaten in der dazugehörigen DFM-Datei (Text). Klicke ich den Button nun an, dann habe ich doch nur ein Grundgerüst und nicht mehr. Ab da hört nun das Geklicke aber auf und ich muss meinen Quelltext schreiben. Und zwar wirklich von Hand. :zwinker:

Soll es wirklich um Programmiersprachen gehen, dann würde ich das am Beispiel von sagen wir mal Delphi und C präsentieren. Zwei Programme, die dasselbe tun. Am Quelltext wird selbst ein Blinder mit Krückstock den Unterschied sehen. IMHO musst Du etwas über die Syntax schreiben und die IDEs vielleicht am Rande trotzdem erwähnen.

das hab ich nicht so gemeint von wegen zusammenklicken und dann ist mein programm fertig,ich weiß schon das man das programm noch schreibne muss bzw. schreiben muss was es zu machen hat wenn ich den button klicke.Bei der dritten generation war es aber noch so,dass man den button selbst programmieren musste.meine frage ist jetzt welche nachteile das mit sich bringt wenn man keine IDE hat sondern nur ein schwarzen bildschirm auf dem man progt?oder auch vorteile?
wo bekomme ich infos zur Syntax?ich kann mir ja wohl schlecht jetzt noch eine proggsprache wie C beibringen....

[Hansa]

Tanja, ein schwarzer Bildschirm ist quasi für DOS-Programme und nicht für Windows. Also für Programme die keine grafische Oberfläche brauchen, z.B. weil sie im Hintergrund laufen sollen, nichts anzeigen sollen, keine Eingabe erwarten usw. Wobei wir wieder bei der IDE wären. Selbst solche Programme schreibt man besser mit der IDE. Z.B. wegen integriertem Compiler, Debugger usw. Es geht aber auch ohne ! Wie gesagt mit beliebigem Editor und dann käme noch der Kommandozeilen-Compiler ins Spiel. Deshalb ja das Beispiel mit dem Button. Man müsste dann die DFM editieren, ohne zu sehen wie sich eine Änderung der Koordinaten auswirkt. Na dann gute Nacht. :mrgreen:

Eh ichs vergesse : der Vorschlag ein C und Delphi-Programm mal gegenüberzustellen, damit war so ein "Hello World" Programm gemeint ! Ich glaube das würde sogar so einem C-Hasser wie mir gelingen. :mrgreen:

[Christian Seehase]

Moin Tanja,

vielleicht solltest Du noch einmal darauf eingehen, welche Unterschiede Du nun herausarbeiten willst.
Die Unterschiede der Sprachen, oder die der Entwicklungsumgebungen.
Wenn Du Dir, z.B., mal ein altes Visual C++ ansiehst, dann kannst Du damit natürlich auch graphische Windows-Programme erstellen, aber mit dem visuellen Erstellen von Oberflächen, wie Du es von Delphi kennst, hat das herzlich wenig zu tun.


@Hansa:

Zitat:

Zitat von Hansa

Tanja, ein schwarzer Bildschirm ist quasi für DOS-Programme und nicht für Windows. Also für Programme die keine grafische Oberfläche brauchen, z.B. weil sie im Hintergrund laufen sollen, nichts anzeigen sollen, keine Eingabe erwarten usw.

Das würde allerdings implizieren, dass es unter DOS keine Programme gegeben hätte, mit denen man interaktiv arbeiten konnte :mrgreen:

[Nuclear-Ping]

Der Vorteil von RAD-IDEs steckt im Namen: Rapid Application Development.

Dadurch dass du nur Buttons, Edit-Felder, Tabellen, Labels, etc. auf deine Form ziehst, durch einen Klick darauf Eigenschaften und Ereignisse bearbeiten und verwalten kannst sparst du eine Menge Zeit, die du sonst in das Programmieren der Controls (Buttons, Labels, ...) und Eventhandler solcher stecken würdest.

Nachteil ist, dass man auf einer Art "Abstraktionsschicht" arbeitet und somit (wie oben schon erwähnt) keine (oder nur sehr schwer) tiefer im System liegende Programme entwickeln kann (Gerätetreiber, Kernel-Programme (Antiviren-Programme, Firewalls), etc. (wenn ich mit letzterem falsch liege, korrigiert mich)).

[DGL-luke]

Hallo, ich hab heir mal angefangen was zusammenzuschreiben: http://luke.delphigl.com/mambo4/inde...d=12&Itemid=15

[Hansa]

Zitat:

Zitat von Christian Seehase

..Das würde allerdings implizieren, dass es unter DOS keine Programme gegeben hätte, mit denen man interaktiv arbeiten konnte :mrgreen:

Nene so nicht. :warn:

Du hast das hier übersehen :

Zitat:

Zitat von Hansa

..quasi für DOS-Programme..z.B. weil sie..

Schreib meinetwegen Deine Programme in Zukunft mit Notepad und compiliere sie mit dcc32. :mrgreen:

[Tanja_michel]

gibt es die seite auch auf deutsch?mit der englischenSprache hab ichs nicht so,sorry :)

[Der_Unwissende]

Zitat:

Zitat von Tanja_michel

meine frage ist jetzt welche nachteile das mit sich bringt wenn man keine IDE hat sondern nur ein schwarzen bildschirm auf dem man progt?oder auch vorteile?

Hi Tanja,
sehr vereinfacht betrachtet handelt es sich immer um die gleichen Unterschiede und Vorteile zwischen älteren Technologien und den Neuen. Ist jetzt etwas zu stark pauschalisiert, trifft nicht auf alles zu, aber doch auf vieles.
Eines der häufigsten Ziele ist es, dass man einfach auf bestehende Lösungen zurückgreifen kann. Bei den heutigen IDEs mit GUI-Designer kann man seine GUI weiterhin auch gänzlich ohne den Designer erstellen. Der Vorteil des GUI-Designer besteht darin, dass sich hier schon jmd. die Arbeit gemacht hat die Windowsfunktionen für den Anwender zu kapseln. So ist es sehr viel einfacher/schneller möglich sich ein GUI "zusammen zu klicken", als das ganze per Hand zu machen. Zudem ist die Wahrscheinlichkeit, dass einem dabei Fehler passieren natürlich sehr gering. Steckt ein Fehler im Code hinter einer Komponente, die zur IDE gehört und benutzen genug Leute die Komponente/IDE, dann wird ein solcher Fehler nicht lange unentdeckt bleiben. Jegliche Änderungen (in Form eines Updates) kommen dann sofort allen Programmen zu gute, die man mit der neuen Version übersetzt.
Natürlich gibt es aber auch hier Nachteile. Die Größe von Programmen wurde ja schon genannt. So waren Rechner vor 10 Jahren natürlich nicht ansatzweise konkurrenzfähig mit heutigen. Speicher war mal, genau wie alle anderen Ressourcen, knapp und teuer. Heute hat sich da so einiges getan. Einer der ganz klaren Vorteile heutiger Compiler/Sprachen/IDEs besteht darin, dass ihnen sehr viel mehr Ressourcen zur Verfügung stehen. Diese sind aber auch nötig! Wird ein Programm automatisch erstellt, so muss hier Code eingefügt werden, der aus verschiedenen Bibliotheken stammt. Hier ist jetzt das Problem, dass der Übersetzer ermitteln muss, ob alle Bibliotheken korrekt eingebunden wurden und damit die Übersetzung möglich ist. Wenn Du Dir mal die Uses-Klausel eines leeren Formulars anschaust, dann siehst Du schon, dass hier eine ganze Menge eingebunden wird. Ob man alle benötigt oder nicht, dass steht dann auf einem anderen Blatt. Man bindet in der Regel viel zu viel ein, was eben die größe der erstellten Exe aufbläht. Zudem werden eventuell sicherheitshalber ein paar Funktionen aufgerufen, deren Effekt durch den ersten Aufruf einer Deiner Funktionen überschrieben wird.
Programmierst Du das per Hand, kannst Du natürlich leicht auf soetwas achten und die entsprechenden Stellen umgehen. An sich ist automatisch generierter Code für eine große Masse gedacht und kann damit weniger auf individuelle Probleme/Optimierungen eingehen. Erstellst Du den Code per Hand, kannst Du hier natürlich sehr viel mehr selbst bestimmen. Das setzt aber auch entsprechend tiefe Kenntnisse voraus.
Natürlich kann auch der automatisch generierte Code dabei deutlich besser als der manuell erstellte Ausfallen, das hängt stark davon ab, wer mit welchem Wissen welchen Code erstellt hat.
An sich kann aber natürlich auch ein Compiler für Dich prüfen, welche Bibliotheken tatsächlich verwendet werden und mit genug Vorgaben/Einschränkungen kannst Du auch sehr gezielt für eine Umgebung ein Programm übersetzen usw. Das ganze kostet dann aber wieder mehr Rechenzeit. Und niemand ist glücklich mit beliebig hohen Zeiten für die Übersetzung!
Auch der Faktor Aktualtität ist nicht zu unterschätzen. Automatisch erzeugter Code kann nur durch ein Update der Umgebung, die diesen erstellt erreicht werden. Bringt jetzt Intel eine neue SSE7-Einheit auf den Markt, dann wird diese natürlich nicht automatisch berücksichtigt. Erstellst Du jetzt allerdings per Hand Code, so kannst Du (sicherlich nur dort wo es wirklich Sinn macht) diese neue Einheit berücksichtigen. Dabei ist es sicherlich nicht jedermanns Sache hier auf Inline-Assembler zurückgreifen zu müssen. Das ganze ist dann sehr viel Fehleranfälliger und muss in jedes einzelne Programm per hand übernommen werden.

[OT]

Zitat:

Zitat von alzaimar

Zitat:

Zitat von Nuclear-Ping

SQL ist eine Datenbank-Abfragesprache, "Structured Query Language".

Stimmt so nicht. Man kann nicht nur Daten abfragen, sondern auch Daten schreiben, Datenbanken, Tabellen etc. basteln ...
Aber eine 'richtige' Programmiersprache wird es damit auch nicht. Immerhin, einen kleinen Compiler kann man damit basteln (Geek-Projekt).

Nun ja, auch darüber kann man sich streiten. Man kann bestimmte "Zellen" (Datensätze) Lesen/Schreiben, sich eine Position merken und ist nicht wirklich in der Anzahl der Zellen beschränkt. Anders gesagt reicht SQL um eine Turing-Maschine zu bauen. Die Programmierung einer universellen TM ist zwar alles andere als komfortabel/praktikabel, aber mit SQL sehr einfach möglich.
Ähnliches gilt auch für z.B. XSLT (sicherlich auch keine Programmiersprache im üblichen Sinne!), reicht halt um eine TM zu bauen.
[/OT]

Gruß Der Unwissende

[mkinzler]

Zitat:

Aber eine 'richtige' Programmiersprache wird es damit auch nicht

Doch SQL gehört zu den Sparceh der 4. Generation im Unterschied zu den prozeduralen/objektorientierten Sprachen der 3. Generation

[DMW]

Zitat:

Zitat von Der_Unwissende

Wenn Du Dir mal die Uses-Klausel eines leeren Formulars anschaust, dann siehst Du schon, dass hier eine ganze Menge eingebunden wird. Ob man alle benötigt oder nicht, dass steht dann auf einem anderen Blatt. Man bindet in der Regel viel zu viel ein, was eben die größe der erstellten Exe aufbläht.
...
An sich kann aber natürlich auch ein Compiler für Dich prüfen, welche Bibliotheken tatsächlich verwendet werden und mit genug Vorgaben/Einschränkungen kannst Du auch sehr gezielt für eine Umgebung ein Programm übersetzen usw.

Das machen aktuelle Compiler/Linker für gewöhnlich auch; Delphi dürfte da keine Ausnahme sein. Was die Programme aufbläht, sind nicht hineinkompilierte überflüssige Funktionen - wenn die der Linker nicht entfernen würde, wäre ein VCL-Projekt mit einem Formular ein paar MB groß. Was so viel Platz benötigt, ist das zugrundeliegende Framework - hier also die Fensterklassenimplementationen, das Persistenzframework, die für Introspektion nötigen Daten etc. Auch ein leeres Formular wird ja schließlich aus einer *.dfm-Ressourcendatei geladen - und dafür wird eben das im Minimalfall ~500 KB große Framework benötigt.

[grenzgaenger]

vergleichen kannste z.b. die jeweiligen generationen

1. Manschinencode
2. Assembler
3. Standardsprachen, wie C/C++, Pascal, Basic
4. Deklarative Sprachen, wie z. B. SQL

Interpreter kanns für 3. Generationssparchen geben z.B. Basic Interpreter/Compieler... etc. <HTH>

PS: Buchtipp: Hansen, Wirtschaftsinformatik
Dies ist eines von 3 Standardwerken zur Einführung in die Informatik, und sollte deine Fragen weitgehend beantworten und ist auch gar nicht teuer.

Hansen, Wirtschaftsinformatik 1

[Der_Unwissende]

Zitat:

Zitat von grenzgaenger

Interpreter kanns für 3. Generationssparchen geben z.B. Basic Interpreter/Compieler... etc. <HTH>

Interpreter kann es auch für die anderen Sprachen geben. So gibt es z.B. Assembler für virtuelle Maschinen, welche dann diesen Assembler nur interpretieren (in den Assembler der Zielarchitektur umwandeln). Sogar unter dem Assembler sind noch Interpreter denkbar (Stichwort CISC vs. RISC).
Auch in der anderen Richtung (über der 3ten) existieren bereits Interpreter, die meisten DBS unterstützen interaktive SQL-Anfragen. Aber auch für andere deklarative Sprachen (wie Prolog) existieren Interpreter.

Gruß Der Unwissende

[grenzgaenger]

da mit dem interpreter zum assembler, geb ich dir recht. hab selbst mal mit 'n emulator (assembler) gearbeitet. aber eine frage hätt ich schon, wo bitte ist prolog deklarativ???? prolog, wie auch lisp, smalltalk gehören zu den sprachen der 4. generation. sind aber IMHO keine deklarativen sprachen. denn bei dennen muss man noch spezifizieren wie man etwas haben möchte (wie beim assembler), nicht was man haben möchte... dagegen kapselt z.b. SQL vollständig die schnittstelle, der anwender braucht nur noch zu sagen was und alles andere übernimmt die DB.

[mkinzler]

Smalltalk ist eine Sprache der 3. generation und wo gibst du bei Prolog bitte an, wie su etwas haben möchtest? Du gibst Fakten und Regeln an und stellst dann "Anfragen", welche dann von der Inferenz-Maschine beantwortet werden.

[grenzgaenger]

die sprachen der KI (z. B. LISP, PROLOG, SMALLTALK) werden zur 5. generation gezählt, also weder zur 3. noch zur 4. dass teilweise konzepte aus der 5G in 3G übernommen wurden, ändert an der einstufung der 3G sprachen jedoch nichts.

[matashen]

Hab hier ein paar Links gefunden die vieleicht hilfreich sein könnten

Link