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 von
alzaimar:
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