Welche Programmiersprache ist die richtige?

[Jürgen Ulmschneider]

Guten Tag an alle !

Ich möchte nun einmal richtige Programme schreiben, also nicht in Perl oder ASP oder so etwas, sondern richtige Programme, die auf einem Rechner laufen.

Jetzt weiss ich nicht, welche Programmiersprache ich dazu verwenden soll und wo ich entsprechende Tutorials und Compiler finden kann.

Ich habe einmal gehört, dass C ganz gut sein soll.
Es soll eine komplexe Sprache mit vielen Möglichkeiten sein, mein erstes Vorhaben, nachdem ich mich ein wenig eingelernt habe, ist ein Adressbuch und danach vielleicht noch ein Terminplaner.
Die Sprache soll jedoch auch dazu fähig sein Editoren, Bildverarbeitungsprogramme, Routenplaner, FTP-Programme, Browser oder sonstiges zu erstellen.
Ich möchte das zwar eigentlich momentan noch keine weiteren Projekte geplanet, aber ich möchte mit dieser Sprache einfach alle Möglichkeiten offen haben.

Kann mir jemand einen Ratschlag geben, und mir saen in welchen Sprachen bekannte Programme, wie z.B. Nero, Norton AV, Total Commander oder KaZaA programmiert wurden ?

Ich kann momentan PHP und die Sprache sollte vom Syntax her so in etwa an PHP herrankommen (ich meine so in etwa, also Vergleichsoperatoren usw) und vor allem nicht zu kompliziert sein (Kompliziert ist natürlich immer relativ, also mit PHP hatte ich keinerlei Probleme beim erlernen, das empfinde ich auch nicht als kompliziert).
Es wäre natürlich auch perfekt, wenn in dieser Sprache viele Funktionen ähnlich wären wie in PHP...

Ich hoffe, dassind nicht zu viele Anforderungen an eine Programmiersprache, es gibt ja meines Wissens auch nur 21 Stück.

Ich hoffe, mir kann jemand einen Ratschlag geben und mir sagen welche Vor - und Nachteile welche Sprache bringt und vielleicht auch einige persönliche Erfahrungen!?
Viele Dank für jeden Tipp, Jürgen.

[Die dicke Tina]

Java Script eignet sich für fast alles.

[wahsaga]

hi,

Java Script eignet sich für fast alles.

es war von _eigenständig lauffähigen_ programmen die rede.

gruss,
wahsaga

[Andavos]

Hallo,

evt. hat sie/er ja auch mal wieder Java mit JavaScript verwechselt, auch wenn diesmal falsch rum :D

MFG
Andavos

[Onkel]

Hi,

Java Script eignet sich für fast alles.

öhem, JS eignet sich eigentlich für gar nix, ausser deine Homepage clientseitig aufzupeppen.

Im Grunde sind JS und PHP gar keine Programmiersprachen; unterschätz den Aufwand für das Erlernen von C oder z.B. Java nicht.

Onkel

[Fabian Transchel]

Hi,

Im Grunde sind JS und PHP gar keine Programmiersprachen; unterschätz den Aufwand für das Erlernen von C oder z.B. Java nicht.

PHP und JavaScript sind Turing-komplett, und das reicht für beide, um "Programmiersprache" sein zu dürfen...

Grüße aus Barsinghausen,
Fabian

[Atomfried]

Java Script eignet sich für fast alles.

Ohne HTML ist Java Script völlig nutzlos. Also fang am besten mit HTML an.

[Johannes Zeller]

Hallo Atomfried,

Ohne HTML ist Java Script völlig nutzlos. Also fang am besten mit HTML an.

HTML ist aber keine Programmiersprache. Und JavaScript kann in der richtigen Umgebung auch ohne HTML sinnvoll sein.

Gruß,

Johannes

[Andavos]

Hallo,
wo finde ich tutorials??
Hmm schonmal an www.google.de gedacht??? Sollte immer weiterhelfen

Also für den Anfang ist Qbasic gut, auch wenn man damit nicht wirklich was anfangen kann. Aber das 1. Prog hat man nach max. 1 Stunde

Dann wenn man Win. mag, dann kann man recht leicht Visual Basic lernen. Damit kann man schon einiges anfangen.

Sonst sind C, und C++ gut.
Damit kann man noch mehr Anfangen als mit VB.

MFG
Andavos

[Markus Trusk]

Hi,
Ich würde mal sagen, dass solche Programme mit C++ programmiert wurden, aber genau weiß ich das auch nicht. Ich würde dir jedenfalls C empfehlen. Damit kannst du ziemlich hardwarenah und auch plattformübergreifend programmieren. Desweiteren ist C/C++ unglaublich leistungsfähig und schnell. (C wurde eigentlich erschaffen um Betriebssysteme zu schreiben)
Java wäre auch noch eine Möglichkeit. Mit Java (oo) kann man sehr schnell Erfolge erzielen und es ist auch sehr schnell zu lernen, da man sich nicht über Grundlegende Dinge wie Speicherreservierung und Freigabe etc. wie bei C/C++ kümmern muss. Desweiteren ist der Vorteil, dass dein Programm überall dort läuft, wo die JVM installiert ist, also wenn es sein muss, sogar in einer Waschmaschine oder Handy =). Der Nachteil von Java ist, dass es ziemlich langsam ist.
Übrigens wenn du solche Programme, wie FTP Programme oder dgl. schreiben willst, genügt nicht einfach nur so etwas wie PHPwissen. Im Grunde ist in PHP schon alles zu unzähligen Funktionen zusammengeschustert, sodaß jeder Anfänger diese Sprache lernen kann, was auch gut ist.
wenn du "richtig" programmieren willst, wirst du um C/C++ nicht herumkommen, aber wenn man sich dahinter hängt, ist es nicht so schwer.

Markus Trusk.

[Andavos]

Hallo,

genügt nicht einfach nur so etwas wie PHPwissen.

PHP-Wissen ist aber nicht schlecht zum Programmieren. Denn man kann evt. die Infos aus dem Manual (von C/C++ etc.) direkt umsetzen, denn evt. weiß man von PHP schon, was die einzelnen Sachen heißen/bedeuten.
Man kann auch evt. gezielter nach Funktionen suchen, z.B. wenn man mit PHP die Array funktion kennt, weiß man evt., wo man das in der anderen Prog. Sprache findet.

Zwar sind PHP kenntnisse nicht zwingend, aber sie schaden auch nicht.

MFG
Andavos

[Markus Trusk]

Hi,

Zwar sind PHP kenntnisse nicht zwingend, aber sie schaden auch nicht.

Natürlich nicht. Ich wollte auch damit nur sagen, dass es nicht genügt mit PHP programmieren zu können, um solche Programme zu schreiben, sondern man muss sich schon einiges mehr an Wissen, aneignen. Eben Speicherverwaltung, einsetzen der verschiedenen Dateitypen, etc.

Markus Trusk.

[Martin Jung]

Hi,

.... Der Nachteil von Java ist, dass es ziemlich langsam ist.

Diese generische Aussage (=Mythos) wird auch durch x-beliebige Wiederholung nicht wahrheitshaltiger.

Viele Grüße,
Martin Jung

[MichaelB]

Hallo,

.... Der Nachteil von Java ist, dass es ziemlich langsam ist.
Diese generische Aussage (=Mythos) wird auch durch x-beliebige Wiederholung nicht wahrheitshaltiger.

Das liegt vorallem an Swing und ist leider zum Teil immer noch so. Naja ... das ist vielleicht nicht ganz exakt formuliert. Sagen wir es besser so: Mit Swing lassen sich generell schon schnelle Programme erzeugen, aber Swing macht es einem leichter als manch andere Toolkits langsamen Programmcode zu erzeugen, auch wenn dieser Effekt nicht mehr ganz so groß ist wie zu vergangenen Tagen.

Gruß
   MichaelB

[Martin Jung]

Hi Michael,

Das liegt vorallem an Swing und ist leider zum Teil immer noch so. Naja ... das ist vielleicht nicht ganz exakt formuliert. Sagen wir es besser so: Mit Swing lassen sich generell schon schnelle Programme erzeugen, aber Swing macht es einem leichter als manch andere Toolkits langsamen Programmcode zu erzeugen, auch wenn dieser Effekt nicht mehr ganz so groß ist wie zu vergangenen Tagen.

100%-ge Zustimmung, allerdings bin ich mir dieser Tatsache bewusst. Im Ausgangsposting hingegen fehlt diese richtige Konkretisierung - _das_ ist mein Problem. Weil, eine Java-Server-Anwendungs (oh gott...) Implementierung beinhaltet i.d.R. eher selten Swing-basierte Komponenten...

Viele Grüße,
Martin Jung

[MichaelB]

Hallo Martin,

Das liegt vorallem an Swing und ist leider zum Teil immer noch so. Naja ... das ist vielleicht nicht ganz exakt formuliert. Sagen wir es besser so: Mit Swing lassen sich generell schon schnelle Programme erzeugen, aber Swing macht es einem leichter als manch andere Toolkits langsamen Programmcode zu erzeugen, auch wenn dieser Effekt nicht mehr ganz so groß ist wie zu vergangenen Tagen.
100%-ge Zustimmung, allerdings bin ich mir dieser Tatsache bewusst.

Na wenigstens einer, der mir mal zustimmt. :-)

Im Ausgangsposting hingegen fehlt diese richtige Konkretisierung - _das_ ist mein Problem.

Naja. Soweit ich verstanden habe ging es um typische Client-Programme wie Editoren (nicht das man NOCH einen bräuchte), Bildbearbeitung usw.

Weil, eine Java-Server-Anwendungs (oh gott...) Implementierung beinhaltet i.d.R. eher selten Swing-basierte Komponenten...

Stimmt. Und bei Serveranwendungen kommen auch noch andere Dinge zum tragen die eher für Java sprechen. Serveranwendungen haben nämlich in der Regel eine recht lange Laufzeit. Das gibt nicht nur den Just-In-Time-Compiler die Möglichkeit vieles in Maschinencode zu übersetzen, sondern auch die dynamische Codeoptimierung zur Laufzeit kommt voll zum tragen

Gruß
   MichaelB

[Martin Jung]

Hi Michael,

Im Ausgangsposting hingegen fehlt diese richtige Konkretisierung - _das_ ist mein Problem.
Naja. Soweit ich verstanden habe ging es um typische Client-Programme wie Editoren (nicht das man NOCH einen bräuchte), Bildbearbeitung usw.

Ja ich weiß - einerseits. Andererseits, sind es ja leider gerade die plakativen Statements, die auch beim flüchtigen Überfliegen hängen bleiben. Da musste ich jetzt einfach einschreiten ;-)

Weil, eine Java-Server-Anwendungs (oh gott...) Implementierung beinhaltet i.d.R. eher selten Swing-basierte Komponenten...
Stimmt. Und bei Serveranwendungen kommen auch noch andere Dinge zum tragen die eher für Java sprechen. Serveranwendungen haben nämlich in der Regel eine recht lange Laufzeit. Das gibt nicht nur den Just-In-Time-Compiler die Möglichkeit vieles in Maschinencode zu übersetzen, sondern auch die dynamische Codeoptimierung zur Laufzeit kommt voll zum tragen.

Hier wird's dann interessant. Frage: Ist dynamische Codeoptimierung nicht sowieso der statischen _prinzipiell_ überlegen? Ist daher Interpretation _auch_ aus Performancegründen ein Konzept der Zukunft?

Viele Grüße,
Martin Jung

[MichaelB]

Hallo Martin,

Weil, eine Java-Server-Anwendungs (oh gott...) Implementierung beinhaltet i.d.R. eher selten Swing-basierte Komponenten...
Stimmt. Und bei Serveranwendungen kommen auch noch andere Dinge zum tragen die eher für Java sprechen. Serveranwendungen haben nämlich in der Regel eine recht lange Laufzeit. Das gibt nicht nur den Just-In-Time-Compiler die Möglichkeit vieles in Maschinencode zu übersetzen, sondern auch die dynamische Codeoptimierung zur Laufzeit kommt voll zum tragen.
Hier wird's dann interessant. Frage: Ist dynamische Codeoptimierung nicht sowieso der statischen _prinzipiell_ überlegen? Ist daher Interpretation _auch_ aus Performancegründen ein Konzept der Zukunft?

Was soll ich sagen außer einem klaren Jaein.  :-)
Dynamische Codeoptimierung setzt ja vorraus, daß zur Laufzeit des Programms eine Art Optimizer läuft der natürlich für seine Arbeit auch gewissen einen Anteil an Rechenleistung benötigt. Und die muss ja zunächst einmal rausgearbeitet werden. Das heißt die Optimierung muss mindestens so gut sein, daß die dadurch gewonnene Rechenzeit den Optimizer mit versorgen kann.
Kommt auch sehr darauf an, wie oft ein optimiertes Codestück aufgerufen wird. Bei einmaligem Aufruf beispielsweise hast Du nur Aufwand aber kein nutzen. Und unglücklicherweise läßt sich auch schwer vorhersagen, wie oft ein bestimmter Codeabschnitt aufgerufen wird oder auch nicht (ausser Du hast beispielsweise eine Schleife mit konstantem Start und Endwert oder dergleichen).
Zudem können geänderte Bedingungen vorherige Optimierungen neutralisieren oder sogar ins negative abrutschen lassen.
Das Ganze ist ein recht komplexes Feld, so dass sich eigentlich nur sagen läßt: Es kommt darauf an.
Man wird einfach Erfahrungen sammeln müssen und letzlich ist es auch eine Frage, wie gut Optimizer in Zukunft werden können.

Gruß
   MichaelB

[Martin Jung]

Moin Michael,

Was soll ich sagen außer einem klaren Jaein.  :-)
Dynamische Codeoptimierung setzt ja vorraus, daß zur Laufzeit des Programms eine Art Optimizer läuft der natürlich für seine Arbeit auch gewissen einen Anteil an Rechenleistung benötigt. Und die muss ja zunächst einmal rausgearbeitet werden. Das heißt die Optimierung muss mindestens so gut sein, daß die dadurch gewonnene Rechenzeit den Optimizer mit versorgen kann.

Ein positives Saldo als Ergebnis ist natürlich eine (implizite) Zielvorgabe für derartige Bemühungen.

Kommt auch sehr darauf an, wie oft ein optimiertes Codestück aufgerufen wird. Bei einmaligem Aufruf beispielsweise hast Du nur Aufwand aber kein nutzen. Und unglücklicherweise läßt sich auch schwer vorhersagen, wie oft ein bestimmter Codeabschnitt aufgerufen wird oder auch nicht (ausser Du hast beispielsweise eine Schleife mit konstantem Start und Endwert oder dergleichen).

Gerade dieser Aspekt kann ja nur zur Laufzeit dynamisch behandelt werden.

Zudem können geänderte Bedingungen vorherige Optimierungen neutralisieren oder sogar ins negative abrutschen lassen.

Das müsste eben zur Laufzeit verhindert werden. Logisch, oder? ;-))

Das Ganze ist ein recht komplexes Feld, so dass sich eigentlich nur sagen läßt: Es kommt darauf an.
Man wird einfach Erfahrungen sammeln müssen und letzlich ist es auch eine Frage, wie gut Optimizer in Zukunft werden können.

Man kann ja 'einfach' die Prinzipien der Prozessoroptimierungen in den virtuellen Prozessor abstrahieren ;-)

Viele Grüße,
Martin Jung

[MichaelB]

Hallo Martin,

Was soll ich sagen außer einem klaren Jaein.  :-)
Dynamische Codeoptimierung setzt ja vorraus, daß zur Laufzeit des Programms eine Art Optimizer läuft der natürlich für seine Arbeit auch gewissen einen Anteil an Rechenleistung benötigt. Und die muss ja zunächst einmal rausgearbeitet werden. Das heißt die Optimierung muss mindestens so gut sein, daß die dadurch gewonnene Rechenzeit den Optimizer mit versorgen kann.
Ein positives Saldo als Ergebnis ist natürlich eine (implizite) Zielvorgabe für derartige Bemühungen.

Es läßt sich aber nicht immer vorhersagen, ob die Sache gut ausgeht oder nicht. Und schon die Entscheidung wie das nun ausgeht, ist nicht simpel.

Kommt auch sehr darauf an, wie oft ein optimiertes Codestück aufgerufen wird. Bei einmaligem Aufruf beispielsweise hast Du nur Aufwand aber kein nutzen. Und unglücklicherweise läßt sich auch schwer vorhersagen, wie oft ein bestimmter Codeabschnitt aufgerufen wird oder auch nicht (ausser Du hast beispielsweise eine Schleife mit konstantem Start und Endwert oder dergleichen).
Gerade dieser Aspekt kann ja nur zur Laufzeit dynamisch behandelt werden.

Ja. Hier setzen ja auch die Optimizer an.

Zudem können geänderte Bedingungen vorherige Optimierungen neutralisieren oder sogar ins negative abrutschen lassen.
Das müsste eben zur Laufzeit verhindert werden. Logisch, oder? ;-))

Aber genau das läßt sich nur sehr schwer bzw. recht begrenzt abschätzen.

Das Ganze ist ein recht komplexes Feld, so dass sich eigentlich nur sagen läßt: Es kommt darauf an.
Man wird einfach Erfahrungen sammeln müssen und letzlich ist es auch eine Frage, wie gut Optimizer in Zukunft werden können.
Man kann ja 'einfach' die Prinzipien der Prozessoroptimierungen in den virtuellen Prozessor abstrahieren ;-)

:-)

Gruß
   MichaelB

[Andreas-Lindig]

Hallo,

...Desweiteren ist der Vorteil, dass dein Programm überall dort läuft, wo die JVM installiert ist...

genau! Das ist irre praktisch an Java. Wenn Du ein Programm geschrieben hast, mußt Du nur noch dazuschreiben, daß der User sich bitteschön erstmal mit der Installation der Java-Umgebung vertraut machen soll und überhaupt, daß er dein Programm ohne tiefere Systemkenntnisse halt nicht wird starten können. Aber das wird Dein User sicherlich gern in Kauf nehmen - für einen Terminplaner ;-)

Gruß, Andreas

[MichaelB]

Hallo MichaelB,

...Desweiteren ist der Vorteil, dass dein Programm überall dort läuft, wo die JVM installiert ist...
genau! Das ist irre praktisch an Java. Wenn Du ein Programm geschrieben hast, mußt Du nur noch dazuschreiben, daß der User sich bitteschön erstmal mit der Installation der Java-Umgebung vertraut machen soll

Ist auch nicht schwerer zu installieren als irgendeine andere Software. Unter Linux einfach
rpm -i jreblabla.rpm
Unter Windows gibt es eine Art setup.exe wo man dann nur "Weiter" klicken muss. Auch nicht weiter tragisch.

und überhaupt, daß er dein Programm ohne tiefere Systemkenntnisse halt nicht wird starten können.

Doppelklick auf das in eine JAR-Datei gepackte Java-Programm. Auch nicht schwerer als das Klicken auf eine EXE-Datei.

Noch einfacher geht es mit Webstart. Vorteil: Das Programm wird bei Bedarf automatisch aktualisiert, falls das notwendig sein sollte.

Zudem kannst Du dem Java-Programm rechtemäßig beschränken. Bei einer EXE-Datei bist Du darauf angewiesen, daß der Autor nichts Böses im Sinn hat. Gerade im Internetzeitalter ein dickes Plus.

Aber das wird Dein User sicherlich gern in Kauf nehmen - für einen Terminplaner ;-)

Es wurde übrigens schon an anderer Stelle erwähnt, daß man aus Java-Programme auch native-executables (auf Deutsch: EXE-Dateien) erzeugen kann und dann kommst Du ohne den JRE-Kram aus.

Gruß
   MichaelB

[MichaelB]

J2SE SDK: http://java.sun.com/j2se/1.4.2/download.html

Dokumentation: http://java.sun.com/j2se/1.4.2/docs/index.html

Tutorial: http://java.sun.com/docs/books/tutorial/index.html

Deutsches Handbuch: http://www.javabuch.de/

Entwicklungsumgebung:
 GEL: http://www.gexperts.com/gel.html
  oder etwas leistungsfähiger aber komplexer
 Eclipse: http://www.eclipse.org/

für kleinere Sachen vielleicht Ruby oder Python.

Oder wenn Du auf MacOS bist dann Objective-C.

Und vergiss den C/C++ Kram wenn Du nicht gerade was Hardwarenahes machen willst.

Gruß
   MichaelB

[Jürgen ulmschneider]

Hallo noch einmal :)

Mus denn, um die fertigen Programme auszuführen auf dem Zielrechner die JVM installiert sein ?
Oder nur bei Webappletts ?

Danke, Jürgen.

[Fabian Transchel]

Hallo,

Mus denn, um die fertigen Programme auszuführen auf dem Zielrechner die JVM installiert sein ?
Oder nur bei Webappletts ?

Nein, immer. In irgendeiner Form muss eine Virtuelle Maschine (die in Zukunft durchaus auch hardwareseitig implementiert sein kann, wie etwa bei Handys zum Teil) den vorkompilierten Java-Bytecode ausführen, sonst tut sich nix.

Grüße aus Barsinghausen,
Fabian

[Christian Seiler]

Hallo Fabian,

Mus denn, um die fertigen Programme auszuführen auf dem Zielrechner die JVM installiert sein ?
Oder nur bei Webappletts ?

Nein, immer. In irgendeiner Form muss eine Virtuelle Maschine (die in Zukunft durchaus auch hardwareseitig implementiert sein kann, wie etwa bei Handys zum Teil) den vorkompilierten Java-Bytecode ausführen, sonst tut sich nix.

Falsch. Man kann Java-Bytecode auch *vor* der Laufzeit zu systemabhängigen Code kompilieren, der GCJ tut dies beispielsweise. Die Virtual Machine ist dann nicht mehr notwendig, um den Code auszuführen. Die Java-API steht bei GCJ auch zur Verfügung, als normale Systembibliothek (unter Windows: DLL), gegen die das Programm gelinkt werden kann.

Viele Grüße,
Christian

[Jürgen Ulmschneider]

Hallo Christian,

Und woher bekomme ich dieses GCJ (offizielle Seite) ?

Danke, Jürgen.

[Christian Seiler]

Hallo Jürgen,

Und woher bekomme ich dieses GCJ (offizielle Seite) ?

http://gcc.gnu.org/java/

Bei mir war das bei Gentoo Linux beim GCC dabei; ob es mit einer Windows-GCC-Version (gibt's einige, bspw. DJGPP) auch dabei ist, weiß ich nicht; aber GCJ ist keine neuartige Idee, es gibt auch andere Compiler, die das auch können; allerdings bin ich in dem Gebiet zu wenig bewandert, um Dir da konkret Namen nennen zu können.

Viele Grüße,
Christian

[MichaelB]

Hallo,

Und woher bekomme ich dieses GCJ (offizielle Seite) ?

http://gcc.gnu.org/java/

Bei mir war das bei Gentoo Linux beim GCC dabei; ob es mit einer Windows-GCC-Version (gibt's einige, bspw. DJGPP) auch dabei ist, weiß ich nicht;

Die Java-Unterstützung der Windows-Version ist meines Wissens nach noch sehr rudimentär. Aber das sagte ich ja bereits ebenso wie den obigen Link, nicht wahr Jürgen?

Gruß
   MichaelB

[Gerrit]

Ich möchte nun einmal richtige Programme schreiben, also nicht in Perl oder ASP oder so etwas, sondern richtige Programme, die auf einem Rechner laufen.

Also mit Perl kannst du schon Programme schreiben, mit PHP auch..

Jetzt weiss ich nicht, welche Programmiersprache ich dazu verwenden soll und wo ich entsprechende Tutorials und Compiler finden kann.

Wenn du dich auf eine festgelegt hast ist das nicht schwer..ich würde aber mit einem richtigen Lehrbuch anfangen, das ist leichter als sich durch n Tutorials zu quälen.

Ich habe einmal gehört, dass C ganz gut sein soll.

Jede Sprache hat ihre Vor- und Nachteile.

Es soll eine komplexe Sprache mit vielen Möglichkeiten sein, mein erstes Vorhaben, nachdem ich mich ein wenig eingelernt habe, ist ein Adressbuch und danach vielleicht noch ein Terminplaner.

Dafür brauchst du noch keine komplexe Programmiersprache ;) Das bekommst du mit allen hin, mit der einen eben etwas schneller als mit der anderen.

Die Sprache soll jedoch auch dazu fähig sein Editoren, Bildverarbeitungsprogramme, Routenplaner, FTP-Programme, Browser oder sonstiges zu erstellen.

Das kannst du mit jeder ausgewachsenen Programmiersprache machen.

Ich hoffe, dassind nicht zu viele Anforderungen an eine Programmiersprache, es gibt ja meines Wissens auch nur 21 Stück.

*lol* es werden wohl ein paar mehr sein..

Ich hoffe, mir kann jemand einen Ratschlag geben und mir sagen welche Vor - und Nachteile welche Sprache bringt und vielleicht auch einige persönliche Erfahrungen!?

Ich gebe mal mein Beschränktes Wissen weiter:

Assembler - Alt, Schwer zu meistern aber höllisch schnell
C/C++ - Komplex,ist am verbreitesten, X Compiler verfügbar, würde ich empfehlen, alle Platformen haben C/C++ Compiler
Basic - Einfach zu lernen, langsam, kann glaube nicht alles
Delphi - Leicht zu lernen, etwas langsamer als C/C++, Programme laufen (unter entsprechender Programmierung) unter Windows/Linux
Java - Leicht zu lernen (soweit ich weiss), langsam aber dafür Platformunabhängig

Das ist ein wenig wie der Windows/Linux/MacOS krieg, oder Netscape vs. IE User, jeder schwört auf "seine" Sprache. Im Moment sind C/C++, Delphi & Java am verbreitesten. Wie schon gesagt würde ich (heute) auf C/C++ setzen da die meisten Programme (und fast jedes kommerzielle Game) darin geschrieben ist. Bin mal auf die anderen Antworten gespannt *g*

mfg

Gerrit

[MichaelB]

Hallo,

Assembler - Alt, Schwer zu meistern aber höllisch schnell

Assembler hat aber auch noch ein paar andere Nachteile. Zum Beispiel Plattformabhängigkeit. Und schnell ist es auch nur dann, wenn man genau weiß was man tut.
Das es schwer lesbarer Code ist und daher schwer zu warten kann man  dadurch kompensieren, dass man seine Programme nicht komplett in Assembler schreibt sondern nur ausgewählte geschwindigkeitskritische Routinen.

C/C++ - Komplex,ist am verbreitesten, X Compiler verfügbar, würde ich empfehlen, alle Platformen haben C/C++ Compiler

C ist (sorry) eine Krankheit. Es gibt so viele Fallstricke bei der Programmierung. Schlecht lesbar ist der Code auch. Zumindest wird man schnell dazu verführt unlesbaren Code zu schreiben.
Und die Objektorientierung von C++ ist ein Witz.

Basic - Einfach zu lernen, langsam, kann glaube nicht alles

Kommt darauf an. Mit VisualBasic beispielsweise kommt man schon recht weit. Aber auch wieder plattformabhängig und es gibt viele unschöne Konstrukte.

Delphi - Leicht zu lernen, etwas langsamer als C/C++, Programme laufen (unter entsprechender Programmierung) unter Windows/Linux

Delphi (bzw. Pascal) ist in der Tat ganz nett. Gut lesbarer Code. Leicht zu lernen. Ganz flott ist es ebenfalls.

Java - Leicht zu lernen (soweit ich weiss), langsam aber dafür Platformunabhängig

Das mit dem langsam kann man so nicht ganz stehen lassen. Die Tage wo Java langsam war liegen schon etwas zurück und das liegt nicht nur daran, daß die computer schneller geworden sind. Viele Java-Anwendungen die ich hier habe sind von der Geschwindigkeit her praktisch nicht mehr von C/C++ zu unterscheiden.
Manchmal hat Java sogar Vorteile (besonders gegenüber C++). Hängt aber auch viel damit zusammen, WIE man programmiert.

Das ist ein wenig wie der Windows/Linux/MacOS krieg, oder Netscape vs. IE User, jeder schwört auf "seine" Sprache.

Da ist was dran :-)

Im Moment sind C/C++, Delphi & Java am verbreitesten. Wie schon gesagt würde ich (heute) auf C/C++ setzen da die meisten Programme

Zumindest im Windows-Umfeld sollen angeblich die meisten Programme in VisualBasic geschrieben sein. Aber das ist eher unerheblich. Wichtiger ist, welche befinden sich in einem dynamsichen Entwicklungsprozess und haben weite Unterstützung. Wieviel Dokumentationen und externe Biblioteken sind verfügbar usw.

Nicht ganz vergessen sollte man vielleicht hierbei die .NET-Sprachen insbesondere C# als ... naja sagen wir mal Java-Klon.

Gruß
   MichaelB

[Christian Seiler]

Hallo,

Viele Java-Anwendungen die ich hier habe sind von der Geschwindigkeit her praktisch nicht mehr von C/C++ zu unterscheiden.

Wenn Sie erst einmal gestartet sind. Ein Java-Programm, das mir die Kommandozeilen-Parameter ausspuckt, braucht merklich länger als ein entsprechendes C oder C++-Programm oder gar PHP-Script. Bei Java muss halt am Anfang der ganze java.lang.*-Krempel etc. in den Speicher geladen werden, und das kostet Zeit. Daher ist Java serverseitig auch nur als Servlet o.ä. sinnvoll, als CGI ist und bleibt Java Selbstmord. ;-)

Aber insofern Zustimmung: Für ein Desktop-Programm, das ständig zumindest im Hintergrund läuft (Terminkalender, Adressbuch), dürfte es keinen wirklichen Geschwindigkeitsunterschied zu C/C++ geben.

Und die Objektorientierung von C++ ist ein Witz.

Ich habe schon *ewig* (d.h. 5 Jahre oder mehr) nichts mehr in C++ gemacht, aber ich fand die Sprache eigentlich OK. Was genau hast Du daran auszusetzen?

Viele Grüße,
Christian

[MichaelB]

Hallo,

Viele Java-Anwendungen die ich hier habe sind von der Geschwindigkeit her praktisch nicht mehr von C/C++ zu unterscheiden.

Wenn Sie erst einmal gestartet sind. Ein Java-Programm, das mir die Kommandozeilen-Parameter ausspuckt, braucht merklich länger als ein entsprechendes C oder C++-Programm oder gar PHP-Script.

Da hast Du vollkommen recht. Die Startzeit ist wirklich nicht berauschend. Deshalb schrieb ich auch in einem anderen Posting, dass ich für kleinere Sachen andere Sprachen (z.B. Skriptsprachen) bevorzugen würde.
Übrigens läßt sich mit einem Trick die Java-VM einmalig starten und im Speicher behalten, so dass der Start der Javaprogramme dann flott geht.
Schade das eine solche Option nicht irgendwo angeboten wird. Liegt vielleicht daran, dass das nicht ganz unproblematisch ist. Es könnte zu Wechselwirkungen zwischen mehreren gleichzeitig gestarteten Java-Programmen kommen.

Bei Java muss halt am Anfang der ganze java.lang.*-Krempel etc. in den Speicher geladen werden, und das kostet Zeit.

Viel Zeit braucht vorallem die Java-VM selbst. Der java.lang. Krempel wie Du ihn nennst sind ja nur Klassen und dir werden erst dann geladen, wenn sie benötigt werden.

Daher ist Java serverseitig auch nur als Servlet o.ä. sinnvoll, als CGI ist und bleibt Java Selbstmord. ;-)

Stimmt: CGI ist nicht anzuraten. Aber wer benutzt heute noch ernsthaft CGI-Skripte im ursprünglichen Sinne?

Aber insofern Zustimmung: Für ein Desktop-Programm, das ständig zumindest im Hintergrund läuft (Terminkalender, Adressbuch), dürfte es keinen wirklichen Geschwindigkeitsunterschied zu C/C++ geben.

Es kommt sicherlich immer auf den Fall an. Aber so groß wie gemeinhin angenommen ist der Unterschied auf keinen Fall. Übrigens ist schon allein C++ gegenüber C sehr viel langsamer. Ein gewisser Overhead scheint alleine schon die Objektorientierung darzustellen.

Und die Objektorientierung von C++ ist ein Witz.
Ich habe schon *ewig* (d.h. 5 Jahre oder mehr) nichts mehr in C++ gemacht, aber ich fand die Sprache eigentlich OK. Was genau hast Du daran auszusetzen?

Vergleiche mal C++ mit Objective-C, dann weißt Du was ich meine.
Es gibt viele Dinge. Vorallem aber ist es der statische Charakter. Ganz im Gegensatz zu Objective-C (oder auch Java), wo es dynamic typing, dynmische Methodensuche / dynamic-runtime-binding (statt virtuelle Methoden wie in C++). Die Botschaften die Objective-C Objekte empfangen können müssen nicht zur Compilezeit feststehen. Es gibt ein sauberen Methoden-Selektor als Alternative zu Funktionszeigern.
Übertrieben gesagt: C++ ist im Prinzip ein C mit einer Sprungtabelle.
Wie statisch die ganze Sache ist sieht man auch daran, dass die ersten C++ Compiler  aus C++ Code C-Code gemacht haben und das dann durch einen C-Compiler gejagt.
Dieses dynamic-runtime-binding erlaubt auch ein viel besseres Objekt-Design als C++. In vielen Fällen sind in C++ Hilfsklassen notwendig die nur dazu dienen bestimmte Konstrukte syntaktisch zu ermöglichen!
Aber es gibt noch weitere Vorteile dieses Verfahrens. So lassen sich zu Klassen von Klassenbiliotheken neue Funktionalitäten hinzufügen ohne die Bilitothek neu zu kompilieren.

MacOS nutzt das late-binding auch hervorragend aus. Bibliotheken und Programme können einfach ins Betriebssystem eingefügt werden, ohne dass eine großartige Installation notwendig ist oder das ganze Gehampel mit der Registry.
Komponenten braucht man nicht speziell zu deinstallieren sondern man löscht sie einfach.

Desweiteren ist die Syntax viel klarer als bei C++. Und das Speichermanagement intelligenter (ok, inzwischen gibt es sogar GarbageCollection für C++ ; passt aber nicht ganz ins Konzept). So läßt sich in Objective-C ein Objekt mit den angehängten Child-Objekten mit einem Schlag freigeben.

Zugegeben, in C++ gibt es auch einige Konstrukte die es in Objective-C nicht gibt. Aber das sind meistens Dinge, die in Objective-C ohnehin anders gehandhabt und daher nicht benötigt werden.

Unterm Strich ist für mich Objective-C das bessere Konzept.

Gruß
   MichaelB

[Christian Seiler]

Hallo Michael,

Ich habe schon *ewig* (d.h. 5 Jahre oder mehr) nichts mehr in C++ gemacht, aber ich fand die Sprache eigentlich OK. Was genau hast Du daran auszusetzen?
Vergleiche mal C++ mit Objective-C, dann weißt Du was ich meine.

Danke für die interessanten Ausführungen, aber ich kenne Objective-C leider überhaupt nicht. Ich werde mir die Programmiersprache mal genauer zu Gemüte führen und dann dein Posting nochmals lesen, um dann evtl. mitreden zu können. :-)

Viele Grüße,
Christian

[Jürgen ulmschneider]

Guten morgen noch einmal;-)

Also ich habe das schon richtig verstanden!?
Im Endeffekt kann man ja dann bei Sprahcne wie C++, Pascal, Delphi usw. nac dem kompilen nicht mehr erkennen in welcher Sprache es geschrieben wurde, weil die Anweisungen der Programmiersprache dann a nur dazu da sind, damit der Compiler weiss, was er als Maschinencode in die engültige EXE-Datei schreibenm soll, oder nicht ?

Wenn das so ist --
Gibt es nicht vielleicht sowas wie einen PHP-Compiler, dann kann ich das Zeug in PHP machen und dann als EXE compilen?

Soory, falls das jetzt irgendwie behindert oderkrank klingt, ich frag ja nur -_-

Danke, Jürgen.

[MichaelB]

Hallo,

Im Endeffekt kann man ja dann bei Sprahcne wie C++, Pascal, Delphi usw. nac dem kompilen nicht mehr erkennen in welcher Sprache es geschrieben wurde, weil die Anweisungen der Programmiersprache dann a nur dazu da sind, damit der Compiler weiss, was er als Maschinencode in die engültige EXE-Datei schreibenm soll, oder nicht ?

Ja. So verhält es sich wohl.

Wenn das so ist --
Gibt es nicht vielleicht sowas wie einen PHP-Compiler, dann kann ich das Zeug in PHP machen und dann als EXE compilen?

Prinzipiell ist das möglich. Allerdings ist mir kein derartiger Compiler bekannt. Evtl. mal im Internet nach suchen.

Gruß
   MichaelB

[Ingo Turski]

Hi,

Also ich habe das schon richtig verstanden!?
Im Endeffekt kann man ja dann bei Sprahcne wie C++, Pascal, Delphi usw. nac dem kompilen nicht mehr erkennen in welcher Sprache es geschrieben wurde, weil die Anweisungen der Programmiersprache dann a nur dazu da sind, damit der Compiler weiss, was er als Maschinencode in die engültige EXE-Datei schreibenm soll, oder nicht ?

Du hast das ganz richtig erkannt. Ganz am Anfang hatte man noch keine Programmiersprache und gab den Maschinencode direkt ein (als Zahlenfolge: Befehl für den jeweiligen Prozesortyp - Parameter). Das war natürlich nicht sehr benutzerfreundlich, da man die ganzen Befehlcodes kennen oder nachschlagen mußte und sich bei Sprüngen im Code die Sprungadressen erst heraussuchen mußte. Dann folgte mit Assembler die Möglichkeit, statt Zahlencodes Befehlskürzel zu verwenden und Sprungadressen mit Namen zu versehen, die dan beim Compilieren ermittelt werden.
Die "höheren" Programmiersprachen vereinfachten die Eingaben dann immer mehr und stellten Befehle mit immer komplexeren dadurch generierten Funktionen zur Verfügung.

Der Nutzen einer Programmiersprache (jedenfalls für den rein privaten Einsatz) steht und fällt mit den Fähigkeiten und der Verbreitung der dazugehörigen Compiler. Unterstützt die Programmiersprache die erforderlichen Funktionen und erzeugt der der Compiler einen ausreichend schnellen ausführbaren Code für die gewünschten Rechner, ist sie auch einsetzbar und die einzige Frage ist dann eigentlich nur, ob sie einem persönlich gefällt, sprich: ob sie den bevorzugten Programmierstil auch unterstützt. Mir persönlich gefällt z.B. PureBasic sehr gut. Die Sprache stellt alle erforderlichen Funktionen auf wirklich einfache Weise zur Verfügung, fordert zwar nicht aber ermöglicht ein strukturiertes Programmieren, ermöglicht die Einbindung von Bibliotheken und Systemfunktionen und der Compiler erzeugt einen extrem kompakten und auch schnellen Code. Zwar nicht plattformunabhängig, aber für den privaten Gebrauch muß es das ja auch nicht sein.

freundliche Grüße
Ingo

[Danny]

Hi,

hier meine Empfehlungen: C, C++, Java, Delphi, Assembler

MfG
Danny

[FrankieB]

Hi,

hier meine Empfehlungen: C, C++, Java, Delphi, Assembler

.... und meine Empfehlungen lauten: Assembler, Basic, Fortran. Damit ist man besser abwärtskompatibel ...)

Grüsse
Frankie

[MichaelB]

Hallo,

hier meine Empfehlungen: C, C++, Java, Delphi, Assembler

.... und meine Empfehlungen lauten: Assembler, Basic, Fortran. Damit ist man besser abwärtskompatibel ...)

Fortran77 oder Fortran90 ? :-)

Vorallem Cobol nicht vergessen. Ist immer noch sehr verbreitet (vorallem bei Banken etc.)

Gruß
  MichaelB

[FrankieB]

Hallo,

Fortran77 oder Fortran90 ? :-)

Wenn's unbedingt sein muss darf's auch Fortran IV sein, Fortran77 ist schon besser, Fortran90 kenne ich nicht ... zuletzt habe ich vor fast 20 Jahren in VAX Fortran 11 von DEC (?) geschrieben.

Grüsse
Frankie

[Bio]

Sup!

Ich möchte nun einmal richtige Programme schreiben, also nicht in Perl oder ASP oder so etwas, sondern richtige Programme, die auf einem Rechner laufen.

Ach, Perl-Programme laufen nicht auf Rechnern?

Die Sprache soll jedoch auch dazu fähig sein Editoren, Bildverarbeitungsprogramme, Routenplaner, FTP-Programme, Browser oder sonstiges zu erstellen.

Jede Turing-vollstaendige Sprache ist dafuer verwendbar...

Ich möchte das zwar eigentlich momentan noch keine weiteren Projekte geplanet, aber ich möchte mit dieser Sprache einfach alle Möglichkeiten offen haben.

Soso.

Ich kann momentan PHP und die Sprache sollte vom Syntax her so in etwa an PHP herrankommen (ich meine so in etwa, also Vergleichsoperatoren usw) und vor allem nicht zu kompliziert sein (Kompliziert ist natürlich immer relativ, also mit PHP hatte ich keinerlei Probleme beim erlernen, das empfinde ich auch nicht als kompliziert).

Wenn jemand schon sagt "Ich kann PHP" ...

Es wäre natürlich auch perfekt, wenn in dieser Sprache viele Funktionen ähnlich wären wie in PHP...

Perl?

Ich hoffe, dassind nicht zu viele Anforderungen an eine Programmiersprache, es gibt ja meines Wissens auch nur 21 Stück.

Ah, Du bist ein Elch...

Gruesse,

Bio

[MichaelB]

Hallo Bio,

Die Sprache soll jedoch auch dazu fähig sein Editoren, Bildverarbeitungsprogramme, Routenplaner, FTP-Programme, Browser oder sonstiges zu erstellen.

Jede Turing-vollstaendige Sprache ist dafuer verwendbar...

Wie zum Beispiel Brainfuck: http://www.muppetlabs.com/~breadbox/bf/
Ernsthaft programmieren kann man damit aber nicht. Wichtig ist nämlich, dass entwprechende Bibliotheken/Toolkits zur Verfügung stehen.

Gruß
  MichaelB

[Bio]

Sup!

Ernsthaft programmieren kann man damit aber nicht. Wichtig ist nämlich, dass entwprechende Bibliotheken/Toolkits zur Verfügung stehen.

Die Bibliotheken/Toolkits kannst Du dann auch in Brainfuck schreiben. Bleibt nur ein maschinenabhaengiger Brainfuck-Interpreter, den Du selbst schreiben musst ;-)

Gruesse,

Bio

[MichaelB]

Hallo Bio,

Ernsthaft programmieren kann man damit aber nicht. Wichtig ist nämlich, dass entwprechende Bibliotheken/Toolkits zur Verfügung stehen.

Die Bibliotheken/Toolkits kannst Du dann auch in Brainfuck schreiben. Bleibt nur ein maschinenabhaengiger Brainfuck-Interpreter, den Du selbst schreiben musst ;-)

*lächel* Da hast Du wohl recht. Aber was leider Brainfuck dazu fehlt ist die Möglichkeit das Betriebssystem anzusprechen. Gäbe es die Möglichkeit externe Assembler/C/[was auch immer]-Routinen einzubinden, ließe sich das bestimmt machen.

Gruß
   MichaelB

[Gerrit]

Wenn jemand schon sagt "Ich kann PHP" ...

Du kannst auch Konsolenprogramme in Pearl schreiben, mit dem GTK sogar mit GUI (auch wenn ich das noch nie probiert habe) aber mit HTML/PHP kannst du auch Plattformunabhängige Clientanwendungen Programmieren..wie gesagt, man KANN, ob es anders nicht einfacher geht ist eine andere Sache..

Nebenbei ist "Ich kann PHP" schon um einiges besser als die Spezies die rausgefunden haben wie Frontpage funktioniert und dann kommen mit "Ich kann HTML" oder die Scriptkiddies: "Ich kann Programmieren, in JavaScript!", das ist Peinlich..mit PHP kann man ganz nette (Web)applikationen machen.

[Gerrit]

Du kannst auch Konsolenprogramme in Pearl schreiben..

PHP meinte ich, nicht diesen größeren Onlineshop ;)

[Noodles]

Servus Jürgen,
auch PHP kann kompliziert sein, wenn man will *g*. Schon mal PHP objektorientiert mit GUI programmiert?
Es gibt für jedes Problem eine Programmiersprache, die etwas am besten kann. Man kann eine Datenbankabfrage auch mit Cobol vornehmen, auch wenn PHP deutlich einfacher wäre. Man muss dabei die einzelnen Stärken und Schwächen der Sprachen beachten (was hier die Stärken und was die Schwächen sind soll jeder für sich festlegen): Sind sie kompiliert?, interpretiert?, objektorientiert?, prozedural?, nur Windows?, plattformunabhängig?, schnelle Textverarbeitung oder Java? :), verfügbare Sourcen und Packages?, Kosten?, Workstation?, Großrechner? (in deinem Fall wohl eher nicht)...
die Liste geht noch ein bißchen weiter.
Ich denke mit Java bist du gut beraten, da ich annehme, dass C++ doch etwas zu komplex für den Anfang ist (Pointer, Speicherfreigabe...)
Der Umstieg von Java auf C++ fällt auch nicht sehr schwer, wenn man diese Sprache mal drauf hat.

Dann ein frohes Programmieren
Noodles

[MichaelB]

Hallo,

Der Umstieg von Java auf C++ fällt auch nicht sehr schwer, wenn man diese Sprache mal drauf hat.

So gesehen ist der Umstieg von Programmiersprache jeder X auf jede Programmiersprache Y nicht schwer, weil die Konzepte meist sehr ähnlich sind (es sei denn man nimmt etwas, was völlig aus der Reihe ist wie zum Beispiel PROLOG).

Schwierig ist es aber trotzdem. Nicht etwa das lernen der neuen Syntax sondern vorallem die neuen Bibliotheken.

Gruß
  MichaelB

[Noodles]

Servus Michael,

so völlig aus der Reihe müssen die Sprachen gar nicht sein, um einen vor große Probleme zu stellen. Wenn du von Java auf C# wechselst, dann gebe ich dir völlig Recht. Aber ein Wechsel von VisualBasic6 auf Java ist schon was anderes, da sich die gesamte Denkweise geändert hat. Ganz abgesehen von den Tausenden { und }, die überall im Weg rumstehen...
Aber wie ich aus ein Paar Postings rauslesen konnte, ist Assembler voll im kommen *g*. das wäre doch mal wieder eine Herausforderung seine alten Kenntnisse aufzufrischen...

Grüße Noodles

[MichaelB]

Hallo,

so völlig aus der Reihe müssen die Sprachen gar nicht sein, um einen vor große Probleme zu stellen. Wenn du von Java auf C# wechselst, dann gebe ich dir völlig Recht. Aber ein Wechsel von VisualBasic6 auf Java ist schon was anderes, da sich die gesamte Denkweise geändert hat. Ganz abgesehen von den Tausenden { und }, die überall im Weg rumstehen...

Ok. Prozeduale Programmierung zu objektorientierter Programmierung ist schon ein Unterschied. Wobei man heutzutage auch in der prozedualen Programmierung versucht, objektorientiert zu coden indem man beispielsweise Code und Daten zusammenhält. Mechnismen wie Vererbung bekommt man zwar nicht so ohne Weiteres umgesetzt, aber immerhin.
Und im konkreten Beispiel VisualBasic gibt es ja zumindest Pseudoobjekte.

Aber wie ich aus ein Paar Postings rauslesen konnte, ist Assembler voll im kommen *g*. das wäre doch mal wieder eine Herausforderung seine alten Kenntnisse aufzufrischen...

Ganz so viel nützen werden einem die alten Assemblerkenntnisse nicht mehr. Zumindest nicht, wenn man maximale Performance rausholen will (ein anderen Grund ausser Spass an der sache gibt es ja für Assemblerprogrammierung nicht).
Konnte man sich früher schön an den Taktzyklen die für ein bestimmten Befehl gebraucht wurden orientieren ist es heutzutage nicht mehr ganz so simpel. Beispielsweise werden Befehle jetzt besonders schnell, wenn sie in einer bestimmten Reihenfolge ausgeführt werden, manche Befehle können parallel bearbeitet werden; andere wiederum nicht usw.

Gruß
  MichaelB

[Christian Kruse]

Hallo MichaelB,

Mechnismen wie Vererbung bekommt man zwar nicht so ohne Weiteres umgesetzt, aber immerhin.

#include <stdlib.h>
#include <stdio.h>

struct s_parent {
  int x;
};

struct s_child {
  struct s_parent base;
  int y;
};

#define S_PARENT(a) ((struct s_parent *)a)

int s_parent_multiply(struct s_parent *this) {
  this->x *= 10;
}

int s_child_multiply(struct s_child *this) {
  this->y *= 10;
}

int main(void) {
  struct s_child x;

S_PARENT(&x)->x = 10;
  x.y = 10;

s_parent_multiply(S_PARENT(&x));
  s_child_multiply(&x);

printf("x: %d, y: %d\n",S_PARENT(&x)->x,x.y);

return EXIT_SUCCESS;
}

Grüße,
 CK

[MichaelB]

Hallo MichaelB,

Mechnismen wie Vererbung bekommt man zwar nicht so ohne Weiteres umgesetzt, aber immerhin.
[Quelltext]

Deshalb schrieb ich auch "nicht so ohne Weiteres" und nicht "unmöglich". Weil das dies unschön anzuschauen ist, wirst Du zugeben müssen. Letzlich kann man in JEDER Sprache objektorientiert programmieren. Es gibt nur Sprachen die unterstützen das besser als andere.

Im übrigen schrieb ich an anderer Stelle schon, daß einige C++ Compiler zunächst C erzeugen und das dann durch ein C-Compiler jagen. Schon daraus geht hervor, daß man in C solche Mechanismen umsetzen kann. Wirklicher Spaß kommt aus meiner Sicht aber dabei nicht auf, wenn man dass "zu Fuß" macht.

Gruß
  MichaelB

[GONZO]

Hi MichaelB,

verwechselst du da nicht gerade prozedurale und imperative Programmierung?

CYa
GONZO

[MichaelB]

Hallo,

verwechselst du da nicht gerade prozedurale und imperative Programmierung?

Dann sag mir, was der Unterschied ist.

Meines Wissens nach ist prozedurale und imperative Programmierung das Gleiche. Exakt gesagt müsste es eigentlich heißen prozedural-imperativ.
Vielleicht könnte man es noch so formulieren, daß reine imperative Programmierung nicht zwingend Prozeduren oder Funktionen enthält. Das wäre beispielsweise ein BASIC ohne GOSUB/RETURN.
In der Praxis eh nicht mehr relevant.

Nicht zu verwechseln ist das alles mit deklarativer Programmierung wie beispielsweise PROLOG.

Gruß
  MichaelB

[Jürgen Ulmschneider]

Hallo und danke erst einmal für alle posts...

Irgendwie mag ich Java nicht, weil ich viele PC's kennen, die Sich bei Java-Appletts im WWW aufhängen.

Muss man zum ausführen der fertigen Programme nachher auch Java installiert haben o.ä. ?

Und ist das so wie Apletts, dass dann drannesteht "Applet wird geladen" oder so ein Käse ?
Oder ist daseinfach wie ein ganz normales Programm ?
Und ist das Plattformunabhängig ?

Und wo finde ich die nötigen Compiler (Wenn man das da braucht) und Tutorials ("Java-Bibel" - sowas wie php.net für PHP - wenn möglich auf deutsch ?)

Danke nochmals, Jürgen.

[MichaelB]

Hallo,

Irgendwie mag ich Java nicht, weil ich viele PC's kennen, die Sich bei Java-Appletts im WWW aufhängen.

Java-Applikationen ist ein bisschen was anderes als Java-Applets.
Im übrigen: Wenn sich ein Programm aufhängt, ist es nicht unbedingt die Schuld der Sprache sondern öfters mal die Schuld des Programmierers.

Muss man zum ausführen der fertigen Programme nachher auch Java installiert haben o.ä. ?

Ja. Einer der Nachteile von Java. Andererseits kommt man auch nicht drum herum irgendwas installiert zu haben, wenn man plattformunabhängig sein möchte.
Im übrigen muss Java für Applikationen nicht zwingend installiert sein. Das JRE kann auch in einem Unterverzeichnis liegen.
Unproblematisch ist die ganze Sache nur so lange, wie man seine Programme nur über Speichermedien/internes Netz weitergibt. Will man sein Programm im Internet zum Download bereitstellen kann es schon lästig sein zusätzlich 15MB für die Java-Maschine downloaden zu müssen.

Und ist das so wie Apletts, dass dann drannesteht "Applet wird geladen" oder so ein Käse ?

Oder ist daseinfach wie ein ganz normales Programm ?

Und ist das Plattformunabhängig ?

Sowohl Applikationen als auch Applets. Vorrausgesetzt es ist eine Java-Maschine installiert bzw. der Browser ist Java-fähig.

Und wo finde ich die nötigen Compiler (Wenn man das da braucht) und Tutorials ("Java-Bibel" - sowas wie php.net für PHP - wenn möglich auf deutsch ?)

Anscheinend hast Du den Thread doch nicht richtig gelesen. Links hierzu (auch deutsch) wurden gepostet.

Gruß
   MichaelB

[Julian von Mendel]

Hi!

Also, ich würde dir VisualBasic, C oder PHP empfehlen.
C ist am schnellsten und kann ungefähr gerundet alles was ein Computer eben so kann. Es gibt für jede ernstzunehmende Plattform einen Compiler, und die Mehrheit der großen Programme sind damit geschrieben. Der Nachteil ist, das man im Vergleich zu z.B. VisualBasic für ein Programm viel viel länger braucht bis da mal was funktioniert, und auch die Einarbeitungszeit ist besonders beim Erstellen grafischer Oberflächen wesentlich höher. Eben vergleischweise kompliziert. Wobei die Syntax der von PHP sehr ähnlich ist.
VisualBasic hebt sich total ab und ist ganz anders - die grafischen Oberflächen werden zusammengeklickt und dann der Code für die verschiedenen Ereignisse geschrieben. Es ist relativ einfach, die Syntax unterscheidet sich aber auch. Immer wieder verwirren tut mich z.B. das da am Ende der Zeile kein Semikolon steht und das Dollarzeichen, um Variablen zu markieren, nicht vor dem Variablennamen, sondern dannach kommt. Außerdem ist VisualBasic nur auf Windows lauffähig und kostenpflichtig.
Du sagst, du kannst PHP. PHP kann man nicht nur für Webseiten nutzen, sondern auch auf dem eigenem Rechner verwenden. Mit PHP-GTK kannst du unter Windows und Linux grafische Oberflächen erzeugen. Nicht so einfach wie mit VisualBasic, aber es geht.
Bei sehr komplexen Sachen ist C also am Besten, für reine Windows-Anwendungen ist VisualBasic am einfachsten und für kleinere Anwendungen kann man PHP-GTK verwenden.

Schöne Grüße,
Julian

[MichaelB]

Hallo,

C ist am schnellsten und kann ungefähr gerundet alles was ein Computer eben so kann. Es gibt für jede ernstzunehmende Plattform einen Compiler,

Problem ist nur, wenn man von einer Plattform auf die andere wechseln möchte. Dann muss man nämlich beim programmieren auch Bibliotheken verwendet haben, die auf mehreren Plattformen zur Verfügung stehen.
Zudem ist auch andere Kriterien wichtig wie Lesbarkeit des Codes, Fehleranfälligkeit der Sprache usw.

und die Mehrheit der großen Programme sind damit geschrieben.

Das würde ich SO nicht unterschreiben.

VisualBasic hebt sich total ab und ist ganz anders - die grafischen Oberflächen werden zusammengeklickt und dann der Code für die verschiedenen Ereignisse geschrieben.

... was einem auch viel Flexiblität nimmt. So kann man nicht auf Ereigenisse reagieren, die dem Form oder den Form-Elementen bisher unbekannt sind. Ebenso lassen sich Elemente schwer neue Eigenschaften hinzufügen.

Du sagst, du kannst PHP. PHP kann man nicht nur für Webseiten nutzen, sondern auch auf dem eigenem Rechner verwenden. Mit PHP-GTK kannst du unter Windows und Linux grafische Oberflächen erzeugen. Nicht so einfach wie mit VisualBasic, aber es geht.

Wobei die Frage ist ob es Sinn macht eine Sprache für Applikationen zu verwenden, die ursprünglich mal nicht dafür gedacht war und deshalb vom Konzept her einige Unzulänglichkeiten hat.
Der einzige Grund wäre, dass man PHP schon kann. Und selbst dann sollte man sich das überlegen.

Bei sehr komplexen Sachen ist C also am Besten

Gerade bei komplexen Sachen kommt man um vernünftige objektorientierung kaum noch herum, was zwar die Erstellung schwieriger macht. Die Pflege und Erweiterung des Programm aber umso einfacher.

Gruß
   MichaelB

[Jürgen Ulmschneider]

Nochmal Hallo ;-)

Also ich denke ich werde mir mal C anschauen (ist da ein Unterschied zu C++? dachte C ist die Abkürzung dafür)

Gibt es irgendwo eine "C-Bibel" auf deutsch ?
Und welchen Compiler (Freeware) könnt ihr mir empfehlen ?

Danke, Jürgen.

[MichaelB]

Hallo,

Also ich denke ich werde mir mal C anschauen (ist da ein Unterschied zu C++? dachte C ist die Abkürzung dafür)

C++ kennt noch zusätzlich den Inkrement-Operator :-))))
Aber mal ernsthaft:
C++ ist im Prinzip ein C was so tut, als wäre es objektorientiert.

Gibt es irgendwo eine "C-Bibel" auf deutsch ?

Im Laden?
Aus dem Kopf weiß ich kein _deutsches_  frei verfügbares Handbuch.
Vielleicht mal danach suchen.

Und welchen Compiler (Freeware) könnt ihr mir empfehlen ?

gcc: http://gcc.gnu.org/
Oder auch Borland C++ http://www.borland.com/products/downloads/download_cbuilder.html in Zusammenabeit mit der IDE: http://www.codecutter.net/tools/Bcc55Tools/Bcc55JFE.htm
Oder auch lcc: http://www.cs.virginia.edu/~lcc-win32/

Gruß
   MichaelB

[Vinzenz]

Hallo Jürgen Ulmschneider,

Also ich denke ich werde mir mal C anschauen (ist da ein Unterschied zu C++? dachte C ist die Abkürzung dafür)

Ja, es ist ein Unterschied zu C++, Nein C ist nicht die Abkürzung dafür.

Bjarne Stroustrup hat C als Basissprache für C++ gewählt, in Kapitel 1.6 seines Buches zu dieser Programmiersprache stehen auch die Gründe dafür :)

Gibt es irgendwo eine "C-Bibel" auf deutsch ?

Programmieren in C
Kernighan/Ritchie

Und welchen Compiler (Freeware) könnt ihr mir empfehlen ?

Den GNU-Compiler.

Noch ein Hinweis zu C/C++ von Bjarne Stroustrup:
Je besser man C kennt, um so schwerer läßt es sich vermeiden, C++-Programme im C-Stil zu schreiben, wobei man allerdings einige der von C++ gebotenen Vorteile verliert.

Tipp: Wenn schon C oder C++, dann fang' gleich mit C++ an :-)

Freundliche Grüsse,

Vinzenz

[MichaelB]

Hallo Vinzenz,

Je besser man C kennt, um so schwerer läßt es sich vermeiden, C++-Programme im C-Stil zu schreiben, wobei man allerdings einige der von C++ gebotenen Vorteile verliert.

Da ist was dran. Aber auch sonst verführt C++ zu nicht ganz sauberer Objektorientierung.

Tipp: Wenn schon C oder C++, dann fang' gleich mit C++ an :-)

Wenn es denn schon ein C sein muss, dann eher Objective-C. Dort hat man viele Dinge weitaus eleganter und sauberer gelöst auch wenn es dadurch weiter weg von C weg ist als C++.

Gruß
   MichaelB

[Klaus Mock]

Hallo,

Wenn es denn schon ein C sein muss, dann eher Objective-C. Dort hat man viele Dinge weitaus eleganter und sauberer gelöst auch wenn es dadurch weiter weg von C weg ist als C++.

Anscheinend ist das wieder einmal ein Fall, in dem die 'schlechtere' Lösung gewonnen hat;-)

Trotzdem würde ich keinem ernsthaft vorschlagen, Objective-C zu verwenden, da es, soweit ich das beurteilen kann, für die Programmierung weit weniger eingesetzt wird als C++, wodurch auhc die Unterstützung durch zus. Bibliotheken sicherlich schlechter ist. Und heutzutage sind imho die Bibliotheken und Komponenten, die man für ein Entwicklungssystem bekommt wesentlicher, als die Qualität der Sprache an sich.

Mir persönlich ist es letztendlich egal, wie toll die Umsetzung irgendwelcher Sprach- bzw. Programmierkonzepte in einer Programmiersprache ist, wenn ich damit das machen kann, was ich machen soll/will.

Grüße
  Klaus

[MichaelB]

Hallo,

Wenn es denn schon ein C sein muss, dann eher Objective-C. Dort hat man viele Dinge weitaus eleganter und sauberer gelöst auch wenn es dadurch weiter weg von C weg ist als C++.
Anscheinend ist das wieder einmal ein Fall, in dem die 'schlechtere' Lösung gewonnen hat;-)

Jaein (mit mehr ja als nein). :-)

Trotzdem würde ich keinem ernsthaft vorschlagen, Objective-C zu verwenden, da es, soweit ich das beurteilen kann, für die Programmierung weit weniger eingesetzt wird als C++, wodurch auhc die Unterstützung durch zus. Bibliotheken sicherlich schlechter ist.

Kommt immer darauf an. Unter Windows oder auch Unix gebe ich Dir durchaus recht. Unter MacOS kommst Du dagegen kaum an Objective-C vorbei. Da ist die C++ Unterstützung ein Graus.

Und heutzutage sind imho die Bibliotheken und Komponenten, die man für ein Entwicklungssystem bekommt wesentlicher, als die Qualität der Sprache an sich.

Stimmt. Deshalb würde ich ja auch zu Java tendieren. Das vereinigt ein halbwegs gutes Sprachkonzept mit umfangreich verfügbaren Bibliotheken, Dokumentation/Support und Plattformunabhängigkeit.

Mir persönlich ist es letztendlich egal, wie toll die Umsetzung irgendwelcher Sprach- bzw. Programmierkonzepte in einer Programmiersprache ist, wenn ich damit das machen kann, was ich machen soll/will.

Oft ist es so, daß für eine gute Lösung man die Programmiersprache nehmen sollte, die auch am besten dafür geeignet ist. In der Praxis scheitert das aber oft daran, daß man nicht gleich gut in mehreren Programmiersprachen sein kann bzw. die Einarbeitung in eine geeignete Sprache zu zeitraubend ist.
Deshalb lohnt es sich als "Hauptsprache" eine Sprache zu nehmen die möglichst vielseitig ist, gut zu handbaben und weit verbreitet. Und da ist Java aus meiner Sicht ein ganz guter Kompromiss.

Gruß
   MichaelB

[Frank Schönmann]

hi!

Trotzdem würde ich keinem ernsthaft vorschlagen, Objective-C zu
verwenden, da es, soweit ich das beurteilen kann, für die
Programmierung weit weniger eingesetzt wird als C++, wodurch auhc
die Unterstützung durch zus. Bibliotheken sicherlich schlechter
ist.

Es gibt Objective-C++, mit dem man C++- und Objective-C-Code mixen
kann.

http://developer.apple.com/documentation/ReleaseNotes/Cocoa/Objective-C++.html

Leider konnte ich mich bislang noch nicht so richtig mit der Syntax
von Objective-C anfreunden.

bye, Frank!

[MichaelB]

Hallo Frank,

Trotzdem würde ich keinem ernsthaft vorschlagen, Objective-C zu
verwenden, da es, soweit ich das beurteilen kann, für die
Programmierung weit weniger eingesetzt wird als C++, wodurch auhc
die Unterstützung durch zus. Bibliotheken sicherlich schlechter
ist.
Es gibt Objective-C++, mit dem man C++- und Objective-C-Code mixen
kann.
http://developer.apple.com/documentation/ReleaseNotes/Cocoa/Objective-C++.html

Interessant zu wissen.
Ohne mich näher damit beschäftigt zu haben, kann ich mir vorstellen, dass das nur in Grenzen möglich ist. C++ und Objective-C unterscheiden sich ja doch beträchtlich.
Software damit erstellen dürfte niemand ernsthaft. Ich könnte mir nur vorstellen, dass es eine Möglichkeit sein soll Altcode übernehmen zu können. Alles andere macht meiner Meinung nach keinen Sinn.

Leider konnte ich mich bislang noch nicht so richtig mit der Syntax
von Objective-C anfreunden.

Es ist halt eine andere Sprache. Man hat den gleichen Lernaufwand wie bei jeder Sprache die man neu hinzu lernt.
Problem ist vielleicht auch noch, wenn man C++ vorbelastet ist. Ich könnte mir vorstellen das man dann dazu neigt Objective-C so zu programmieren wie C++. Und das geht dann natürlich total schief. Man muss schon relativ unvoreingenommen da herangehen.
Ich denke mal, dass jemand der vorher noch nicht objektorientiert programmiert hat sich in Objective-C besser einarbeiten kann als in C++.

Gruß
   MichaelB

[Frank Schönmann]

hi!

http://developer.apple.com/documentation/ReleaseNotes/Cocoa/Objective-C++.html
Interessant zu wissen.
Ohne mich näher damit beschäftigt zu haben, kann ich mir
vorstellen, dass das nur in Grenzen möglich ist. C++ und
Objective-C unterscheiden sich ja doch beträchtlich.

Steht ja in dem Dokument, was alles moeglich ist: man kann C++-
Objekte in Objective-C verwenden und umgekehrt. Dadurch ist es
moeglich, zb. C++-Klassenbibliotheken in seinem Objective-C-Code
zu verwenden.

Es ist allerdings nicht moeglich, C++- und Objective-C-Klassen in
der gleichen Klassenhierarchie zu verwenden.

Leider konnte ich mich bislang noch nicht so richtig mit der
Syntax von Objective-C anfreunden.
Es ist halt eine andere Sprache. Man hat den gleichen Lernaufwand
wie bei jeder Sprache die man neu hinzu lernt.

Ich denke, dass ich mich recht schnell in neue Sprachen einarbeiten
kann. Die Syntax von Objective-C ist auch kein grosses Problem. Sie
gefaellt mir einfach in Teilen nicht besonders.

Problem ist vielleicht auch noch, wenn man C++ vorbelastet ist.
Ich könnte mir vorstellen das man dann dazu neigt Objective-C so
zu programmieren wie C++. Und das geht dann natürlich total
schief. Man muss schon relativ unvoreingenommen da herangehen.

Ich habe Objective-C bisher nur mal ueberflogen und noch nicht viel
damit gemacht. Aber um mal ein wahlloses Beispiel herauszugreifen,
das mir gerade einfaellt: ich mag es nicht, dass ich Konstruktoren
in Objective-C explizit aufrufen muss und habe darin bisher auch
nicht viel Sinn gesehen. Ich koennte mir vorstellen, dass das ein
wenig mit dem Alter der Sprache zusammenhaengt.

bye, Frank!

[MichaelB]

Hallo Frank,

http://developer.apple.com/documentation/ReleaseNotes/Cocoa/Objective-C++.html
Interessant zu wissen.
Ohne mich näher damit beschäftigt zu haben, kann ich mir
vorstellen, dass das nur in Grenzen möglich ist. C++ und
Objective-C unterscheiden sich ja doch beträchtlich.
Steht ja in dem Dokument, was alles moeglich ist: man kann C++-
Objekte in Objective-C verwenden und umgekehrt. Dadurch ist es
moeglich, zb. C++-Klassenbibliotheken in seinem Objective-C-Code
zu verwenden.

Überflogen habe ich es jetzt inzwischen. :-)
Sicherlich kann man Objekte gegenseitig verwenden. Aber ich denke dabei gibt es ganz klare Grenzen. Das geht auch aus dem Artikel hervor. So das es eben nicht so ohne Weiteres geht jedes x-beliebige Objekt zu verwenden. Wie gesagt. Es gibt klare Unterschiede. So kennt C++ Mehrfachvererbung. Die gibt es so in Objective-C nicht. Dafür kennt die wiederum Protokolle die man in C++ vergeblich sucht. Auch die dynamische Typisierung und das late-binding sind völlig andere Konzepte wie in C++.

Es ist allerdings nicht moeglich, C++- und Objective-C-Klassen in
der gleichen Klassenhierarchie zu verwenden.

Genau darauf wollte ich unter anderem hinaus. :-)

Leider konnte ich mich bislang noch nicht so richtig mit der
Syntax von Objective-C anfreunden.
Es ist halt eine andere Sprache. Man hat den gleichen Lernaufwand
wie bei jeder Sprache die man neu hinzu lernt.

Ich denke, dass ich mich recht schnell in neue Sprachen einarbeiten
kann. Die Syntax von Objective-C ist auch kein grosses Problem. Sie
gefaellt mir einfach in Teilen nicht besonders.

Liegt auch an der Art der Erweiterung von C. Bei C++ hat man recht viele Schlüsselworte zu diesem Zweck eingeführt. Bei Objective-C sind es weniger und sie wirken durch ihre Art und Weise ... na wie soll ich sagen .... die objectorientierung wirkt wie in C eingebettet (wie beispielsweise PHP in HTML).

Wenns nach dem gefallen geht, müsste man eigentlich eine Sprache wie Pascal oder auch Modula nehmen. Diese sind sehr gut lesbar, sehr klar und relativ nah an der menschlichen Ausdrucksweise ohne dabei aber übermäßig viel Schreibarbeit zu erzeugen.

Problem ist vielleicht auch noch, wenn man C++ vorbelastet ist.
Ich könnte mir vorstellen das man dann dazu neigt Objective-C so
zu programmieren wie C++. Und das geht dann natürlich total
schief. Man muss schon relativ unvoreingenommen da herangehen.

Ich habe Objective-C bisher nur mal ueberflogen und noch nicht viel
damit gemacht. Aber um mal ein wahlloses Beispiel herauszugreifen,
das mir gerade einfaellt: ich mag es nicht, dass ich Konstruktoren
in Objective-C explizit aufrufen muss und habe darin bisher auch
nicht viel Sinn gesehen.

Gibt einem andererseits auch Flexibilität, so dass man den Konstruktor nur aufrufen muss, wenn man es braucht (viele Objekte haben ja einfach nur ein leeren Konstruktor). Und indem man es bewußt tut ist auch klarer was passiert. In C++ ist mit neuanlage eines Objektes zwei Dinge gemacht. Erstens Speicher reserviert und zweitens der Konstruktor aufgerufen. Zwei unterschiedliche Dinge in einem Befehl.
Wichtiger ist aber die Philosophie von Objective-C zu der ein impliziter Kontruktoraufruf nicht unbedingt passt.

Ich koennte mir vorstellen, dass das ein
wenig mit dem Alter der Sprache zusammenhaengt.

Naja. Objective-C und C++ sind etwa zur selben Zeit entstanden.

Gruß
   MichaelB

[Christian Seiler]

Hallo Michael,

Wenns nach dem gefallen geht, müsste man eigentlich eine Sprache wie Pascal oder auch Modula nehmen. Diese sind sehr gut lesbar, sehr klar und relativ nah an der menschlichen Ausdrucksweise ohne dabei aber übermäßig viel Schreibarbeit zu erzeugen.

Ich persönlich habe früher (bevor ich C gelernt habe) reht viel mit Pascal (für DOS) gearbeitet und C gefällt mir besser. Das liegt vor allem daran, dass ich bei C deutlich mehr 'Luft' habe, da die ganzen Konstrukte nicht den kompletten Bildschirm zukleistern. So kann ich mich schneller am Code orientieren und erkennen, was dieser macht (sofern er ordentlich eingerückt ist, versteht sich). Bei Pascal etc. fällt mir das deutlich schwerer - und daher brauche ich auch länger, um in Pascal etwas zu programmieren, was nicht unbedingt an der Schreibarbeit liegt. Von daher mag ich Sprahen mit C-ähnlicher Syntax lieber als Sprachen mit einer Syntax, bei der so Dinge wie BEGIN und END usw. drin stehen.

Viele Grüße,
Christian

[MichaelB]

Hallo,

Wenns nach dem gefallen geht, müsste man eigentlich eine Sprache wie Pascal oder auch Modula nehmen. Diese sind sehr gut lesbar, sehr klar und relativ nah an der menschlichen Ausdrucksweise ohne dabei aber übermäßig viel Schreibarbeit zu erzeugen.
Ich persönlich habe früher (bevor ich C gelernt habe) reht viel mit Pascal (für DOS) gearbeitet

Das kann ja dann fast nur Turbo Pascal gewesen sein. :-)

und C gefällt mir besser. Das liegt vor allem daran, dass ich bei C deutlich mehr 'Luft' habe, da die ganzen Konstrukte nicht den kompletten Bildschirm zukleistern.

Du meinst die Übersichtlichkeit ist besser ... ja bisschen was dran ist schon.
Allerdings verführt C mit seinen Abkürzungsmöglichkeiten auch dazu letzlich unleserlichen Code zu schreiben. Man muss viel mehr Disziplin an den Tag legen und deutlich mehr dokumentieren.

So kann ich mich schneller am Code orientieren und erkennen, was dieser macht (sofern er ordentlich eingerückt ist, versteht sich). Bei Pascal etc. fällt mir das deutlich schwerer - und daher brauche ich auch länger, um in Pascal etwas zu programmieren, was nicht unbedingt an der Schreibarbeit liegt.

Dafür sind viele Dinge in C katastrophal gelöst.
Das fängt schon bei ganz simplen Dingen an wie Arrays. So beginnen Arrays in C immer mit 0 auch wenn ich das gar nicht haben will.
In Pascal kann ich sagen Array[5..15] usw. falls ich das mal brauche (das konnte sogar BASIC schon) und vorallem ist auch gleich klar wenn man sich den Code anschaut, wo dass Array beginnt und wo es endet.
Die Splittung von Headerdateien und Programmdateien bringt ebenfalls viele Probleme mitsich (doppelter Pflegeaufwand) und tragen nicht gerade zur Übersichtlichkeit bei.
C kennt nicht die häufig benötigten Strings sondern nur nullterminierte Array of Char. Das ist fehleranfällig und schon einfache Operationen wie das Feststellen der Länge eines Strings nötigt mich die Bytes zu zählen (was auch nicht gerade positiv für die Perforamce ist).
Mengen und Bereiche fehlen gänzlich in C.
Ich kann nicht einfach mal sagen
if ch in ['ä','ö','ü','ß','Ä','Ö','Ü'] usw.
sondern muss immer
if (ch=='ä' || ch=='ö' || ch=='ü' || ch=='ß' || ch=='Ä' || ch=='Ö' || ch=='Ü')
Das soll übersichtlicher sein?
Das fehlen von Bereichen macht Programme fehleranfällig. In Pascal kann ich sagen:
Type jahreszahlen = 1970..2500
Und die Realisierung von Aufzählungstypen in C ist ein Witz:
enum wochentag = {Mo, Di, Mi, Do, Fr, Sa, So};
...
wochentag=Di; //funktioniert
wochentag=2;  // funktioniert auch!!!
Da kann ich gleich mit int-Konstanten arbeiten. Da weiß ich wenigstens, woran ich bin.

Letzlich ist es aber Geschmacksfrage. Und über Geschmack läßt sich bekanntlich streiten. :-)

Gruß
  MichaelB

PS: In Java (oder auch C#) hat man zumindest einige Dinge etwas besser gelöst als in C. Trotzdem hat man eine eine an C angelehnte Syntax. Ich könnte mir vorstellen, dass das eine interessante Sprache für Dich wäre.

[Christian Kruse]

Hallo MichaelB,

Dafür sind viele Dinge in C katastrophal gelöst.

Und viele Dinge sind in Pascal so gar nicht möglich.

Das fängt schon bei ganz simplen Dingen an wie Arrays. So beginnen Arrays in C immer
mit 0 auch wenn ich das gar nicht haben will.

Die Philosophie, die da hinter steckt: das herunterrechnen des Indexes kannst du als
Programmierer auch selber tun.

In Pascal kann ich sagen Array[5..15] usw.

Pascal ist auch keine Sprache für Programmierer. Pascal ist eine Sprache für Anfänger.

falls ich das mal brauche (das konnte sogar BASIC schon) und vorallem ist auch gleich
klar wenn man sich den Code anschaut, wo dass Array beginnt und wo es endet.

Das ist bei C genau so:

char array[100];

Fängt bei 0 an, hört bei 99 auf.

Die Splittung von Headerdateien und Programmdateien bringt ebenfalls viele Probleme
mitsich (doppelter Pflegeaufwand) und tragen nicht gerade zur Übersichtlichkeit bei.

Das Gegenteil ist der Fall. Die Header-Dateien bilden recht gut die Trennung von
Deklaration und Implementation ab. In Pascal musste man diese sehr dämlichen
forward;-Konstrukte bilden. Der Pflege-Aufwand war dort übrigens in dem Fall der
gleiche.

BTW. ist die Trennung in .c- und .h-Dateien reine Konventions-Sache. Die kannst du auch
nach belieben auflösen.

C kennt nicht die häufig benötigten Strings sondern nur nullterminierte Array of Char.

Das war in Pascal übrigens nicht besser. Da war es eine Stufe abstrahierter, aber dafür
konnte ein String maximal 255 Zeichen lang werden.

Das ist fehleranfällig und schon einfache Operationen wie das Feststellen der Länge
eines Strings nötigt mich die Bytes zu zählen

Das war auch in Pascal notwendig. Einziger Unterschied: es musste maximal 255 mal
addiert werden statt, wie in C, maximal unendlich mal.

(was auch nicht gerade positiv für die Perforamce ist).

Zähle halt mit.

Mengen und Bereiche fehlen gänzlich in C.
Ich kann nicht einfach mal sagen
if ch in ['ä','ö','ü','ß','Ä','Ö','Ü'] usw.
sondern muss immer
if (ch=='ä' || ch=='ö' || ch=='ü' || ch=='ß' || ch=='Ä' || ch=='Ö' || ch=='Ü')
Das soll übersichtlicher sein?

Dafür gibt es switch().

switch(ch) {
  case 'ä':
  case 'ö':
  case 'ü':
  case 'ß':
  case 'Ä':
  case 'Ö':
  case 'Ü':
    tu_was();
    break;
}

Das fehlen von Bereichen macht Programme fehleranfällig.

Das ist nun wirklich aus der Luft gegriffen.

In Pascal kann ich sagen:
Type jahreszahlen = 1970..2500
Und die Realisierung von Aufzählungstypen in C ist ein Witz:
enum wochentag = {Mo, Di, Mi, Do, Fr, Sa, So};
...
wochentag=Di; //funktioniert
wochentag=2;  // funktioniert auch!!!

Nein, funktioniert nicht. Es ist nicht definiert, welche Zahl der Compiler für Di
auswählt. Wenn du sichergehen willst, dass Di mit zwei indiziert wird, musst du die
Definition wie folgt ändern:

enum wochentage = {
  Mo = 1,
  Di = 2,
  Mi = 3,
  Do = 4,
  Fr = 5,
  Sa = 6,
  So = 7
};

Da kann ich gleich mit int-Konstanten arbeiten. Da weiß ich wenigstens, woran ich bin.

Wenn du C kannst, weisst du auch so, woran du bist. Wenn du es nicht oder nur unzureichend
kannst, ist es unwichtig für dich.

Nene, Pascal war in vielerlei Hinsicht nix besser als C, was die Konstruktionen betraf.
Wenn man da ein bisschen über "das Normale"[tm] herausging und es wirklich effektiv nutzen
wollte, stiess man dort an die gleichen Probleme wie in C. Auch in Pascal musste ich, wenn
ich dynamisch grosse Arrays haben wollte, mit Pointern hantieren.

Grüße,
 CK

[MichaelB]

Hallo CK,

Dafür sind viele Dinge in C katastrophal gelöst.
Und viele Dinge sind in Pascal so gar nicht möglich.

Das musst Du mir mal näher erklären. Beide sind Turing-complete. Was soll also in C möglich sein was in Pascal nicht möglich ist?
Mag sein das in einer Sprache einige Dinge etwas umständlicher sind als in der anderen. Aber eine Unmöglichkeit folgt daraus nicht.

Das fängt schon bei ganz simplen Dingen an wie Arrays. So beginnen Arrays in C immer
mit 0 auch wenn ich das gar nicht haben will.
Die Philosophie, die da hinter steckt: das herunterrechnen des Indexes kannst du als
Programmierer auch selber tun.

Ja ich kann und MUSS es selber tun. Für mich ein Rückschritt ohne Zwang. Wenn es danach geht können wir ALLES selber tun und uns in die Assemblerprogrammierung zurückziehen.
Programmiersprachen sollen dem Programmierer das Leben erleichtern. Und da finde ich es nicht besonders clever, wenn etwas Bestehendes wieder wegrationalisiert wird.

In Pascal kann ich sagen Array[5..15] usw.
Pascal ist auch keine Sprache für Programmierer. Pascal ist eine Sprache für Anfänger.

Ohne vernüftige Begründung bleibt das eine Aussage auf dem Niveau wie  "Windows ist für DAUs und Linux für Profis".

falls ich das mal brauche (das konnte sogar BASIC schon) und vorallem ist auch gleich
klar wenn man sich den Code anschaut, wo dass Array beginnt und wo es endet.
Das ist bei C genau so:
char array[100];
Fängt bei 0 an, hört bei 99 auf.

Was ich meinte (so schrieb ich es auch), dass es eben beim hinschauen nicht klar ist weil es nur implizit ist und nicht explizit. Die Lesbarkeit leidet darunter.
Und in der Praxis ist es nicht immer so, daß es sinnvoll ist die Zählung mit 0 zu beginnen. Da muss man dann wieder umrechnen usw. ein Aufwand, den man sich eigentlich sparen könnte.

Die Splittung von Headerdateien und Programmdateien bringt ebenfalls viele Probleme
mitsich (doppelter Pflegeaufwand) und tragen nicht gerade zur Übersichtlichkeit bei.

Das Gegenteil ist der Fall. Die Header-Dateien bilden recht gut die Trennung von
Deklaration und Implementation ab. In Pascal musste man diese sehr dämlichen
forward;-Konstrukte bilden. Der Pflege-Aufwand war dort übrigens in dem Fall der
gleiche.

Irgendwie sehe ich nicht den rechten Sinn in dieser Trennerei (wegen der Übersichtlichkeit dafür gibts moderne IDEs). Allenfalls das besch* Konzept von C macht dies manchmal notwendig (ohne dabei irgendein Benefit zu liefern).

BTW. ist die Trennung in .c- und .h-Dateien reine Konventions-Sache. Die kannst du auch
nach belieben auflösen.

Das ist allerdings richtig. Nur nützt mir das wenig, wenn ich vorhandenen Code übernehmen muss. Weil landläufig wird diese Trennung vorgenommen.

C kennt nicht die häufig benötigten Strings sondern nur nullterminierte Array of Char.
Das war in Pascal übrigens nicht besser. Da war es eine Stufe abstrahierter, aber dafür
konnte ein String maximal 255 Zeichen lang werden.

Stimmt. Das war zumindest unter Turbo Pascal so. Das ist keine Schwäche der Sprache generell, sondern der Implementierung. Ich weiß gar nicht, ob dass in den modernen Pascaldialekten noch der Fall ist. Weil es macht keinen Sinn mehr angesichts des heute verfügbaren RAMs.

Das ist fehleranfällig und schon einfache Operationen wie das Feststellen der Länge
eines Strings nötigt mich die Bytes zu zählen
Das war auch in Pascal notwendig. Einziger Unterschied: es musste maximal 255 mal
addiert werden statt, wie in C, maximal unendlich mal.

Falsch. Zumindest die Implementierung in Turbo Pascal war es so, daß die Länge am Anfang des Strings gespeichert wurde.

(was auch nicht gerade positiv für die Perforamce ist).
Zähle halt mit.

Brauch ich ja wieder eine extra Variable. Wofür? Wo es mir doch andere Sprachen wesentlich einfacher machen.

Mengen und Bereiche fehlen gänzlich in C.
Ich kann nicht einfach mal sagen
if ch in ['ä','ö','ü','ß','Ä','Ö','Ü'] usw.
sondern muss immer
if (ch=='ä' || ch=='ö' || ch=='ü' || ch=='ß' || ch=='Ä' || ch=='Ö' || ch=='Ü')
Das soll übersichtlicher sein?

Dafür gibt es switch().

switch(ch) {
  case 'ä':
  case 'ö':
  case 'ü':
  case 'ß':
  case 'Ä':
  case 'Ö':
  case 'Ü':
    tu_was();
    break;
}

Sorry. Aber das ist ja noch länger. *kopfschüttel*

Das fehlen von Bereichen macht Programme fehleranfällig.
Das ist nun wirklich aus der Luft gegriffen.

Wieso? Ein konkretes Beispiel habe ich gleich mitangegeben:

In Pascal kann ich sagen:
Type jahreszahlen = 1970..2500

In C müsste ich ein int nehmen und müsste sämtliche Bereichsüberprüfungen von Hand machen. Zu Assemblerzeiten war das ja noch akzeptabel. Heutzutage will ich schlanken, lesbaren und fehlerunanfälligen Code haben.

Und die Realisierung von Aufzählungstypen in C ist ein Witz:
enum wochentag = {Mo, Di, Mi, Do, Fr, Sa, So};
...
wochentag=Di; //funktioniert
wochentag=2;  // funktioniert auch!!!
Nein, funktioniert nicht. Es ist nicht definiert, welche Zahl der Compiler für Di

Doch. Der C-Compiler vergibt implizit Nummern sofern nicht eine eigene angegeben ist. Für C sind enums nichts weiter als int-Werte und die möglichen Werte nichts anderes als int-Konstanten.
Und sowas ist für mich kein Aufzählungstyp sondern ... na ich weiß nicht was. Das selbe gibt ja auch für ein praktisch nicht vorhandenes Boolean.

auswählt. Wenn du sichergehen willst, dass Di mit zwei indiziert wird, musst du die
Definition wie folgt ändern:
[Quelltext]

Toll. Nur das es überhaupt nicht das ist, was ich haben will.

Wenn du C kannst, weisst du auch so, woran du bist. Wenn du es nicht oder nur unzureichend
kannst, ist es unwichtig für dich.

Ich beklage mich auch nur darüber, daß C einem es unnötig(!) schwer macht.

Nene, Pascal war in vielerlei Hinsicht nix besser als C, was die Konstruktionen betraf.
Wenn man da ein bisschen über "das Normale"[tm] herausging und es wirklich effektiv nutzen
wollte, stiess man dort an die gleichen Probleme wie in C.

Schon die Strenge Typisierung in Pascal vermeidet viele Probleme (das ist auch der Grund, warum man das in Java wieder eingeführt hat).
Dadurch werden viele Fehler abgefangen, die sonst erst zur Laufzeit auftreten.
Diverse implizite Checks tragen ebenfalls dazu bei.

Die weitaus meisten Fehler (und damit Sicherheitslücken) die in Programmen auftreten liegen nicht nur daran, daß C so verbreitet ist sondern an den teilweise kaputten Konzept. Andere Sprachen haben solche Probleme prinzipbedingt nicht.
Man lädt sich mit C einfach eine Menge Balast auf der in meinen Augen gar nicht notwendig ist.

Auch in Pascal musste ich, wenn
ich dynamisch grosse Arrays haben wollte, mit Pointern hantieren.

Pointer brauche ich immer, wenn ich mit Arrays dynamischer Größe (also praktisch Listen) arbeite.
Aber üblicherweise implementiert man sowas einmal (falls nicht sogar schon in einer Bibliothek vorhanden) und verwendet es dann nur noch. Das ist in der Tat bei beiden Sprachen gleich gut/schlecht. So richtig komfortabel wird das dann erst, wenn man die in der OOP üblichen Collections verwendet.

Gruß
   MichaelB

[Christian Kruse]

Hallo MichaelB,

Dafür sind viele Dinge in C katastrophal gelöst.
Und viele Dinge sind in Pascal so gar nicht möglich.
Das musst Du mir mal näher erklären. Beide sind Turing-complete. Was soll also in C
möglich sein was in Pascal nicht möglich ist?

Ein String länger als X. Ich sage extra: ein String. Wenn ich mit Pointern arbeite, bin
ich wieder bei C-Zuständen.

Das fängt schon bei ganz simplen Dingen an wie Arrays. So beginnen Arrays in C immer
mit 0 auch wenn ich das gar nicht haben will.
Die Philosophie, die da hinter steckt: das herunterrechnen des Indexes kannst du als
Programmierer auch selber tun.
Ja ich kann und MUSS es selber tun. Für mich ein Rückschritt ohne Zwang.

Die Philosophie von C ist Minimalismus. Wenn dir das nicht gefällt, wähle eine andere
Sprache.

In Pascal kann ich sagen Array[5..15] usw.
Pascal ist auch keine Sprache für Programmierer. Pascal ist eine Sprache für Anfänger.
Ohne vernüftige Begründung bleibt das eine Aussage auf dem Niveau wie  "Windows ist für
DAUs und Linux für Profis".

Pascal wurde als Lehr-Sprache entwickelt. Dementsprechend ist das Abstraktionslevel,
die Syntax und dementsprechend ist der Aufwand, den man betreiben muss, wenn man bestimmte
Konstrukte erreichen will.

C ist nicht als Lehrsprache entwickelt worden. C ist eine Sprache für Programmierer. Das
merkt man sowohl an der Syntax als auch an den Freiheiten und dem Abstraktions-Grad.

falls ich das mal brauche (das konnte sogar BASIC schon) und vorallem ist auch gleich
klar wenn man sich den Code anschaut, wo dass Array beginnt und wo es endet.
Das ist bei C genau so:
char array[100];
Fängt bei 0 an, hört bei 99 auf.
Was ich meinte (so schrieb ich es auch), dass es eben beim hinschauen nicht klar ist

Es ist auf den ersten Blick klar. Ich schaue hin und weiss sofort: der Array ist 100 Zeichen
lang, erstes Byte liegt bei 0 und letztes Byte liegt bei 99.

Die Splittung von Headerdateien und Programmdateien bringt ebenfalls viele Probleme
mitsich (doppelter Pflegeaufwand) und tragen nicht gerade zur Übersichtlichkeit bei.

Das Gegenteil ist der Fall. Die Header-Dateien bilden recht gut die Trennung von
Deklaration und Implementation ab. In Pascal musste man diese sehr dämlichen
forward;-Konstrukte bilden. Der Pflege-Aufwand war dort übrigens in dem Fall der
gleiche.
Irgendwie sehe ich nicht den rechten Sinn in dieser Trennerei (wegen der Übersichtlichkeit
dafür gibts moderne IDEs).

Nicht jeder benutzt IDEs. Ich persönliche z. B. benutze keine IDE. Ich schaue in die
Header-Datei, wenn ich etwas wissen will.

Allenfalls das besch* Konzept von C macht dies manchmal notwendig (ohne dabei irgendein
Benefit zu liefern).

Das Konzept ist hierbei dasselbe wie bei Pascal. Zeilenweises kompilieren. Wie gesagt, in C
sind es Prototypen und in Pascal waren es forward-Deklarationen. Kein Unterschied.

BTW. ist die Trennung in .c- und .h-Dateien reine Konventions-Sache. Die kannst du auch
nach belieben auflösen.
Das ist allerdings richtig. Nur nützt mir das wenig, wenn ich vorhandenen Code übernehmen
muss. Weil landläufig wird diese Trennung vorgenommen.

Sie ist ja auch durchaus sinnvoll. Das nennt man in der hiesigen Lehrsprache das
'Geheimnisprinzip'.

C kennt nicht die häufig benötigten Strings sondern nur nullterminierte Array of Char.
Das war in Pascal übrigens nicht besser. Da war es eine Stufe abstrahierter, aber dafür
konnte ein String maximal 255 Zeichen lang werden.
Stimmt. Das war zumindest unter Turbo Pascal so.

Das war nicht nur unter Turbo Pascal so.

Das ist fehleranfällig und schon einfache Operationen wie das Feststellen der Länge
eines Strings nötigt mich die Bytes zu zählen
Das war auch in Pascal notwendig. Einziger Unterschied: es musste maximal 255 mal
addiert werden statt, wie in C, maximal unendlich mal.
Falsch. Zumindest die Implementierung in Turbo Pascal war es so, daß die Länge am Anfang
des Strings gespeichert wurde.

Turbo Pascal ist kein Massstab.

(was auch nicht gerade positiv für die Perforamce ist).
Zähle halt mit.
Brauch ich ja wieder eine extra Variable. Wofür? Wo es mir doch andere Sprachen wesentlich
einfacher machen.

Die machen es genau so: entweder mitzählen oder jedesmal neu zählen. Davon mal ab hält dich
keiner davon ab, einen eigenen String-Baukasten zu schreiben. Das ist ganz einfach. Schau
dir den Source dieses Forums an.

[... switch ...]
Sorry. Aber das ist ja noch länger. *kopfschüttel*

Die Länge ist unerheblich.

Das fehlen von Bereichen macht Programme fehleranfällig.
Das ist nun wirklich aus der Luft gegriffen.
Wieso? Ein konkretes Beispiel habe ich gleich mitangegeben:
In Pascal kann ich sagen:
Type jahreszahlen = 1970..2500
In C müsste ich ein int nehmen und müsste sämtliche Bereichsüberprüfungen von Hand machen.

Und wo ist das bitte sehr fehleranfällig?
Nein, sags mir nicht, die Buzzwords sind und bleiben immer die selben.

Und die Realisierung von Aufzählungstypen in C ist ein Witz:
enum wochentag = {Mo, Di, Mi, Do, Fr, Sa, So};
...
wochentag=Di; //funktioniert
wochentag=2;  // funktioniert auch!!!
Nein, funktioniert nicht. Es ist nicht definiert, welche Zahl der Compiler für Di
Doch. Der C-Compiler vergibt implizit Nummern sofern nicht eine eigene angegeben ist.

Das sagte ich dir gerade. Es ist nur nicht definiert, welche Nummer er vergibt. Statt 2
könnte er auch eine beliebige andere Zahl aus dem int-Zahlenraum nehmen. Einzige Bedingung,
die gestellt wird: sie müssen direkt aufeinander folgen.

auswählt. Wenn du sichergehen willst, dass Di mit zwei indiziert wird, musst du die
Definition wie folgt ändern:
[Quelltext]
Toll. Nur das es überhaupt nicht das ist, was ich haben will.

Du hast nicht verstanden, warum ich dir das geschrieben habe. Macht nix. Lies mein Posting
einfach nochmal.

Wenn du C kannst, weisst du auch so, woran du bist. Wenn du es nicht oder nur unzureichend
kannst, ist es unwichtig für dich.
Ich beklage mich auch nur darüber, daß C einem es unnötig(!) schwer macht.

Wenn dir diese Philosophie nicht gefällt, wähle eine andere Sprache. Gibt genug.

Nene, Pascal war in vielerlei Hinsicht nix besser als C, was die Konstruktionen betraf.
Wenn man da ein bisschen über "das Normale"[tm] herausging und es wirklich effektiv nutzen
wollte, stiess man dort an die gleichen Probleme wie in C.
Schon die Strenge Typisierung in Pascal vermeidet viele Probleme (das ist auch der Grund,
warum man das in Java wieder eingeführt hat).

Das ist doch Humbug. Die Typisierung ist in Pascal gleich wie in C. Arbeite ich mit
Pointern, kann ich mich über jede Typisierung hinwegsetzen. Tue ich das nicht, muss ich
mich dran halten. Pascal wie C.

Die weitaus meisten Fehler (und damit Sicherheitslücken) die in Programmen auftreten
liegen nicht nur daran, daß C so verbreitet ist sondern an den teilweise kaputten Konzept.

Belege?

Auch in Pascal musste ich, wenn
ich dynamisch grosse Arrays haben wollte, mit Pointern hantieren.
Pointer brauche ich immer, wenn ich mit Arrays dynamischer Größe (also praktisch Listen)
arbeite.

Nein. Siehe PHP, Perl, Ruby, Python, Java, etc, pp.

Aber üblicherweise implementiert man sowas einmal (falls nicht sogar schon in einer
Bibliothek vorhanden) und verwendet es dann nur noch.

Dann mach das doch. Weder in C noch in Pascal hält dich etwas davon ab.

Grüße,
 CK

[MichaelB]

Hallo CK,

Dafür sind viele Dinge in C katastrophal gelöst.
Und viele Dinge sind in Pascal so gar nicht möglich.
Das musst Du mir mal näher erklären. Beide sind Turing-complete. Was soll also in C
möglich sein was in Pascal nicht möglich ist?

»»

Ein String länger als X. Ich sage extra: ein String. Wenn ich mit Pointern arbeite, bin
ich wieder bei C-Zuständen.

Äh ... ok. Pointer gibt es auch in Pascal. Du sagtest etwas von "gar nicht möglich".
Und auf solche Fälle warte ich immer noch.
Auf unzulänglichkeiten in Konstrukten hinzuweisen, die es in C nichtmal gibt hat nichts mit der oben genannten Frage zu tun.

Das fängt schon bei ganz simplen Dingen an wie Arrays. So beginnen Arrays in C immer
mit 0 auch wenn ich das gar nicht haben will.
Die Philosophie, die da hinter steckt: das herunterrechnen des Indexes kannst du als
Programmierer auch selber tun.
Ja ich kann und MUSS es selber tun. Für mich ein Rückschritt ohne Zwang.

»»

Die Philosophie von C ist Minimalismus. Wenn dir das nicht gefällt, wähle eine andere
Sprache.

*lol* Wenn ich eine minimalistische Sprache nehmen will dann nehm ich eine Stackmaschine oder eine Programmiersprache wie Brainfuck (http://www.muppetlabs.com/~breadbox/bf/).
Es stimmt schon, daß C darauf ausgelegt ist möglichst wenig Schlüsselworte zu verwenden. Um das aufzufangen braucht man dann schon für primitivste Sachen Bibliotheksfunktionen.
Hat natürlich auch einen entscheidenen Vorteil. Man kann bei Bedarf sehr viele Dinge reimplementieren.
Noch eines zu den Schlüsselworten. C hat zwar wenig Schlüsselworte aber das wird dadurch ausgeglichen das im übermäßigen Maß Operatoren verwendet werden.
Und apropos Operator: Ganz krank ist ja nun dieses = für eine Zuweisung und == für Vergleich. Ich möchte nicht wissen, wie oft Programmierer darüber geflucht haben wenn in vielen unbeabsichtigen Verwechslungsfällen der Compiler keine Fehlermeldung liefert. --> Krankes Konzept da nicht am Menschen orientiert.
Übrigens versuche ich tatsächlich C aus dem Weg zu gehen. Nicht immer läßt sich das aber vermeiden.

In Pascal kann ich sagen Array[5..15] usw.
Pascal ist auch keine Sprache für Programmierer. Pascal ist eine Sprache für Anfänger.
Ohne vernüftige Begründung bleibt das eine Aussage auf dem Niveau wie  "Windows ist für
DAUs und Linux für Profis".
Pascal wurde als Lehr-Sprache entwickelt. Dementsprechend ist das Abstraktionslevel,
die Syntax und dementsprechend ist der Aufwand, den man betreiben muss, wenn man bestimmte
Konstrukte erreichen will.
C ist nicht als Lehrsprache entwickelt worden. C ist eine Sprache für Programmierer. Das
merkt man sowohl an der Syntax als auch an den Freiheiten und dem Abstraktions-Grad.

Das ist ja alles recht hochtrabendes Gerade ... was mir fehlt sind konkrete praxisrelevante Beispiele.
Wenn C die Sprache für Real-World-Programmer ist, dann muss es doch irgendwas praxisrelevantes und _konkretes_ geben, was sich in Pascal nur schwer umsetzen läßt.

falls ich das mal brauche (das konnte sogar BASIC schon) und vorallem ist auch gleich
klar wenn man sich den Code anschaut, wo dass Array beginnt und wo es endet.
Das ist bei C genau so:
char array[100];
Fängt bei 0 an, hört bei 99 auf.
Was ich meinte (so schrieb ich es auch), dass es eben beim hinschauen nicht klar ist

»»

Es ist auf den ersten Blick klar. Ich schaue hin und weiss sofort: der Array ist 100 Zeichen
lang, erstes Byte liegt bei 0 und letztes Byte liegt bei 99.

Aber nur aufgrund impliziten Wissens.
Einer der noch nie Pascal programmiert hat (aber Erfahrung in Programmierung hat) wird sich in Pascal besser zurecht finden als jemand der noch nie C programmiert hat in einem C-Programm.
Ok aber darauf will ich jetzt nicht ewig herumreiten. Ich habe auch kein Problem mit dieser Definition von Feldern. Damit komme ich ganz gut klar. Was mir weniger gefällt ist eben nur, daß man keinen Startwert angeben kann.

Die Splittung von Headerdateien und Programmdateien bringt ebenfalls viele Probleme
mitsich (doppelter Pflegeaufwand) und tragen nicht gerade zur Übersichtlichkeit bei.
»»
Das Gegenteil ist der Fall. Die Header-Dateien bilden recht gut die Trennung von
Deklaration und Implementation ab. In Pascal musste man diese sehr dämlichen
forward;-Konstrukte bilden. Der Pflege-Aufwand war dort übrigens in dem Fall der
gleiche.
Irgendwie sehe ich nicht den rechten Sinn in dieser Trennerei (wegen der Übersichtlichkeit
dafür gibts moderne IDEs).

»»

Nicht jeder benutzt IDEs. Ich persönliche z. B. benutze keine IDE.

Da kann ich nur sagen: Selbst schuld.
Wenn Du Dir das Leben unnötig schwer machst, dann ist das Dein Problem. Schieb es dann aber nicht auf die Sprache wenn Dir dann irgendwas fehlt.
Ohne zusätzliche Software sind viele Sachen aufgrund der Komplexität gar nicht mehr vernünftig handhabbar. Denk nur an UML usw.
Und sowas sehe ich nicht als Aufgabe der Programmiersprache sich auch noch darum zu kümmern. Wie war das doch gleich mit der minimalistischen Philosophie von C? Alles klar!

[Fortsetzung folgt]

[MichaelB]

Allenfalls das besch* Konzept von C macht dies manchmal notwendig (ohne dabei irgendein
Benefit zu liefern).

»»

Das Konzept ist hierbei dasselbe wie bei Pascal. Zeilenweises kompilieren. Wie gesagt, in C
sind es Prototypen und in Pascal waren es forward-Deklarationen. Kein Unterschied.

Das mit dem forward ist in der Tat nicht sehr clever (zum Glück haben das moderne Programmiersprachen überwunden). Ich sage ja auch nicht das ALLES an Pascal besser ist. Manches aber schon.

BTW. ist die Trennung in .c- und .h-Dateien reine Konventions-Sache. Die kannst du auch
nach belieben auflösen.
Das ist allerdings richtig. Nur nützt mir das wenig, wenn ich vorhandenen Code übernehmen
muss. Weil landläufig wird diese Trennung vorgenommen.
Sie ist ja auch durchaus sinnvoll. Das nennt man in der hiesigen Lehrsprache das
'Geheimnisprinzip'.

Nunja. Das Geheimprinzip kommt eher aus der OOP-Ecke. Zumindest wird es dort erst ordentlich umgesetzt.
Wie dem auch sei. Auch dafür brauche ich keine Header-Dateien.

C kennt nicht die häufig benötigten Strings sondern nur nullterminierte Array of Char.
Das war in Pascal übrigens nicht besser. Da war es eine Stufe abstrahierter, aber dafür
konnte ein String maximal 255 Zeichen lang werden.
Stimmt. Das war zumindest unter Turbo Pascal so.
Das war nicht nur unter Turbo Pascal so.

Nullterminierende Speicherbereiche kann man in Pascal genauso nehmen.
Hier hat Pascal eben nur was, was C fehlt. Ist also schwer das als Nachteil für Pascal zu werten. :-)

Das ist fehleranfällig und schon einfache Operationen wie das Feststellen der Länge
eines Strings nötigt mich die Bytes zu zählen
Das war auch in Pascal notwendig. Einziger Unterschied: es musste maximal 255 mal
addiert werden statt, wie in C, maximal unendlich mal.
Falsch. Zumindest die Implementierung in Turbo Pascal war es so, daß die Länge am Anfang
des Strings gespeichert wurde.
Turbo Pascal ist kein Massstab.

Meinens Wissens nach ist es auch unter vielen anderen Pascal-Dialekten so. Bei Turbo Pascal war die Längenangabe eine Byte-Variable. Daher auch nur 255 Zeichen. Manch andere verwenden dafür Integer und dann hat man schon deutlich mehr.

(was auch nicht gerade positiv für die Perforamce ist).
Zähle halt mit.
Brauch ich ja wieder eine extra Variable. Wofür? Wo es mir doch andere Sprachen wesentlich
einfacher machen.
Die machen es genau so: entweder mitzählen oder jedesmal neu zählen. Davon mal ab hält dich
keiner davon ab, einen eigenen String-Baukasten zu schreiben. Das ist ganz einfach. Schau
dir den Source dieses Forums an.

Das mit der Länge war ja nur ein Beispiel. Nullterminierende Zeichenketten haben ja noch andere Nachteile. Beispielsweise Copy&Paste. Was ist wenn ein Paste über die reservierte Länge hinausgeht. Was ist wenn das Ende-null durch irgendwas vorloren geht. Das Konzept ist einfach unsicherer und schwerer zu handhaben.

[... switch ...]
Sorry. Aber das ist ja noch länger. *kopfschüttel*
Die Länge ist unerheblich.

Es ging um Übersichtlichkeit und Lesbarkeit des Programms. Und da spielt die Länge schon eine Rolle.

Das fehlen von Bereichen macht Programme fehleranfällig.
Das ist nun wirklich aus der Luft gegriffen.
Wieso? Ein konkretes Beispiel habe ich gleich mitangegeben:
In Pascal kann ich sagen:
Type jahreszahlen = 1970..2500
In C müsste ich ein int nehmen und müsste sämtliche Bereichsüberprüfungen von Hand machen.
Und wo ist das bitte sehr fehleranfällig?

Man. Du machst es einem aber nicht einfach.
Das zum Beispiel einer Jahreszahl oder auch einer Monatsangabe (das Beispiel ist vielleicht deutlicher) ein Wert zugewiesen werden kann, der logisch gesehen gar nicht gültig ist. So lassen sich Programmfehler leichter finden und das arbeiten mit ungültigen Werten verhindern. In der Datenbankwelt nennt man sowas Constraints. Aber die verwendest Du ja wahrscheinlich auch nicht. Das ist ja nur was für Weicheier.

Und die Realisierung von Aufzählungstypen in C ist ein Witz:
enum wochentag = {Mo, Di, Mi, Do, Fr, Sa, So};
...
wochentag=Di; //funktioniert
wochentag=2;  // funktioniert auch!!!
Nein, funktioniert nicht. Es ist nicht definiert, welche Zahl der Compiler für Di
Doch. Der C-Compiler vergibt implizit Nummern sofern nicht eine eigene angegeben ist.

»»

Das sagte ich dir gerade. Es ist nur nicht definiert, welche Nummer er vergibt. Statt 2
könnte er auch eine beliebige andere Zahl aus dem int-Zahlenraum nehmen. Einzige Bedingung,
die gestellt wird: sie müssen direkt aufeinander folgen.

Verstehst Du denn nicht, worauf ich hinaus will?
Das man überhaupt eine int-Zahl zuweisen kann ist das Problem! Wozu brauche ich ein benutzerdefinierten Typ wenn im Fall des Falles dem Compiler sowieso alles egal ist.

Wenn du C kannst, weisst du auch so, woran du bist. Wenn du es nicht oder nur unzureichend
kannst, ist es unwichtig für dich.
Ich beklage mich auch nur darüber, daß C einem es unnötig(!) schwer macht.

»»

Wenn dir diese Philosophie nicht gefällt, wähle eine andere Sprache. Gibt genug.

Ich werde das Gefühl nicht los, daß bei C gar keine Philosophie dahinter steckt (ausser den Programmierer zu verwirren). Viele Dinge sind einfach nur unlogisch. Sowas wie Durchgängigkeit fehlt mir.
Warum müssen Prozeduren einen Datentyp (void) zurückgeben? Warum kann man bei einer mit void deklarierten Funktion überhaupt ein Rückgabewert angeben ohne das der Compiler meckert?
Eine Zuweisung geschieht so:
a=5;
Aber bei typedef ist es genau andersherum
typedef alt neu
Der Operatorreihenfolge ist ungeschickt gewählt. Beispiel:
int a;
a=10;
--x=(++x)--;
Hier kommt 11 raus und nicht 9 wie man (intuitiv) erwarten würde. Das nötigt einem viele Klammern zu setzen (vorallem bei Vergleichen), was der Übersichtlichkeit nicht gerade zuträglich ist.
Auch die Mehrfachverwendung von Schlüsselwörtern mit jeweils komplett unterschiedlicher Bedeutung macht es einem nicht gerade einfach (beispielsweise: static).
Viele Dinge in C sind nicht geregelt und implementierungsabhängig (Umfang von Datentypen usw).

Als Problematisch sehe ich auch den Präprozessor wenngleich er ein mächtiges Werkzeug sein kann (ich selbst vermisse ihn manchmal bei anderen Sprachen). Neben den vielen Unwegsamkeiten (so werden Typen von Makroargumenten nicht überprüft oder unliebsamen Seiteneffekten) sind Makrolastige Programme auch relativ schwer zu debuggen weil das Kompilat und der Quelltext eben nicht mehr soviel miteinander zu tun haben.
Nungut. Man muss ihn ja nicht verwenden wirst Du jetzt wieder sagen. Oftmals kommt man aber nicht umhin, um andere C Schwächen auszugleichen (beispielsweise wenn man plattformübergreifend programmiert).

Nene, Pascal war in vielerlei Hinsicht nix besser als C, was die Konstruktionen betraf.
Wenn man da ein bisschen über "das Normale"[tm] herausging und es wirklich effektiv nutzen
wollte, stiess man dort an die gleichen Probleme wie in C.
Schon die Strenge Typisierung in Pascal vermeidet viele Probleme (das ist auch der Grund,
warum man das in Java wieder eingeführt hat).
Das ist doch Humbug. Die Typisierung ist in Pascal gleich wie in C. Arbeite ich mit
Pointern, kann ich mich über jede Typisierung hinwegsetzen. Tue ich das nicht, muss ich
mich dran halten. Pascal wie C.

Es gibt den untypisierten Pointer auch in Pascal. Das stimmt. Und damit kann man sich dann über alle Typprüfungen hinwegsetzen.
Aber generell sind Pointer in Pascal typisiert (im Gegensatz zu C).

Zeiger sind immer fehleranfällig. In vielen Fällen wo man in C ein Zeiger benötigt braucht man in Pascal keinen und vermeidet dadurch die Fehlerquelle. Zum Beispiel Strings (statt CharArray) und ein echtes Call-by-Reference.

Was die anderen Datentypen angeht da wird es noch deutlicher. In C kann ich jeden Variablen den Wert einer anderen zuweisen egal welcher Typ es ist. Das geht in Pascal so nicht (wozu auch?). Daraus folgt: Bestimmte Fehler können prinzipbedingt nicht auftreten.

Die weitaus meisten Fehler (und damit Sicherheitslücken) die in Programmen auftreten
liegen nicht nur daran, daß C so verbreitet ist sondern an den teilweise kaputten Konzept.
Belege?

Schau mal in jede x-beliebige Security-Mailingliste. Da wirst Du öfter auf Meldungen treffen wie "Sicherheitsproblem durch BufferOverflow" etc. Ok. BufferOverflows gibt es in Pascal auch. Aber die Konstrukte die dazu führen können werden in Pascal wesentlich weniger benötigt.

Auch in Pascal musste ich, wenn
ich dynamisch grosse Arrays haben wollte, mit Pointern hantieren.
Pointer brauche ich immer, wenn ich mit Arrays dynamischer Größe (also praktisch Listen)
arbeite.
Nein. Siehe PHP, Perl, Ruby, Python, Java, etc, pp.

Auch da wird mit Pointern handtiert, wenngleich es auch gut verborgen wird.
Ich kenne jetzt nur Java genauer. Für die anderen Sprachen kann ich nichts sagen. Übrigens. Das Zeigerkonzept (sofern man das Zeiger nennen kann) bei Java ist vorbildlich und extrem sicher vor Programmierfehlern. Nicht zuletzt wegen der strengen Typisierung (es gibt keine typenlosen Zeiger).

Aber üblicherweise implementiert man sowas einmal (falls nicht sogar schon in einer
Bibliothek vorhanden) und verwendet es dann nur noch.
Dann mach das doch. Weder in C noch in Pascal hält dich etwas davon ab.

Eben.

Ich will es mal so formulieren:
C ist darauf getrimmt, daß man sehr viel im Code selbst optimieren kann und das zu lasten der Übersichtlichkeit und Sicherheit. Das ist aber heutzutage gar nicht mehr notwendig, weil die Compiler sehr viel besser geworden sind.
Für hardwarenahe Programmierung (Treiber/Betriebssyteme usw.) hat C durchaus seine Vorteile. Das will ich gar nicht mal abstreiten. Aber für die meisten anderen Belange gibt es Besseres.

Gruß
   MichaelB

[Klaus Mock]

Hallo,

Meinens Wissens nach ist es auch unter vielen anderen Pascal-Dialekten so. Bei Turbo Pascal war die Längenangabe eine Byte-Variable. Daher auch nur 255 Zeichen. Manch andere verwenden dafür Integer und dann hat man schon deutlich mehr.

Weiter unten kritisierst Du die Implementierungsabhängigkeit von Datentypen bei C, bei Pascal ist das für Dich in Ordnung, oder wie?

Das mit der Länge war ja nur ein Beispiel. Nullterminierende Zeichenketten haben ja noch andere Nachteile. Beispielsweise Copy&Paste. Was ist wenn ein Paste über die reservierte Länge hinausgeht. Was ist wenn das Ende-null durch irgendwas vorloren geht. Das Konzept ist einfach unsicherer und schwerer zu handhaben.

C wurde an sich dafür entwickelt, um Betriebssysteme schreiben zu können, ohne alles in Assembler zu machen, damit dieses Betriebssystem möglichst einfach auf eine neue Hardware portiert werden kann. Irgendwie ist imho C so ein Mittelding zwischen Assembler und Hochsprachen wie Pascal oder Fortran oder ähnlichem.
Da Betriebssystem-Funktionen in der Regel sehr oft aufgerufen werden macht es sinn, diese so performant wie möglich zu machen. Wenn nun aufwendige Prüfungen auch dann jedesmal gemacht, wenn in einem bestimmten Code-Abschnitt die Prüfbedingungen garantiert nie verletzt werden können, dann leidet die Performance darunter. Daher muß man sich um Prüfungen selbst kümmern, wenn man sich unsicher ist, ob da nicht was komplett falsches auch daherkommen kann.

Ein weiteres Ziel bei der Entwicklung von C war, sie möglichst einfach zu gestalten, was die Core-Syntax betrifft, damit die Erstellung eines Compilers für eine neue Plattform so einfach wie möglich ist. Alles was nicht direkt in der Sprache notwendig ist, wurde in die Bibliotheken verlagert.
Ausserdem, wozu soll ich denn File-Handling-Funktionen in eine Sprache einbauen, wenn das OS auf dem das Programm dann läuft vielleicht gar keine Dateien kennt?

Warum müssen Prozeduren einen Datentyp (void) zurückgeben?

Weil es in C so etwas wie Prozeduren gar nicht gibt. Es gibt nur Funktionen, die nichts (void) zurückliefern;-)

Warum kann man bei einer mit void deklarierten Funktion überhaupt ein Rückgabewert angeben ohne das der Compiler meckert?

Dann verwendest Du anscheinen keinen Ansi-Compiler.

Der Operatorreihenfolge ist ungeschickt gewählt. Beispiel:
int a;
a=10;
--x=(++x)--;

Na gut, nicht alles was möglich ist, ist auch sinnvoll. Das von Dir gewählte Beispiel hätte ich nie und nimmer geschrieben.

Und apropos Operator: Ganz krank ist ja nun dieses = für eine Zuweisung und == für Vergleich. Ich möchte nicht wissen, wie oft Programmierer darüber geflucht haben wenn in vielen unbeabsichtigen Verwechslungsfällen der Compiler keine Fehlermeldung liefert. --> Krankes Konzept da nicht am Menschen orientiert.

Die meisten Compiler die ich kenne, geben eine Warning aus, wenn innerhalb von Bedingungen Zuweisungen erfolgen. Das aber nur so nebenbei.
Ich persönlich fluche eher, weil ich in Pascal bei jeder Zuweisung := verwenden muß, nur damit ich bei den, viel seltener benötigten, Vergleichen ein einfaches = verwenden kann. Da gefällt mir das C-Konzept viel besser (genauso wie es anscheinend auch den Entwicklern von praktisch allen Sprachen, die C-ähnliche Syntax verwenden genug gefallen hat, um es zu übernehmen).

Auch die Mehrfachverwendung von Schlüsselwörtern mit jeweils komplett unterschiedlicher Bedeutung macht es einem nicht gerade einfach (beispielsweise: static).

Da hast Du sicherlich recht, allerdings ist dieser Makel auch in vielen anderen Sprachen anzutreffen.

Viele Dinge in C sind nicht geregelt und implementierungsabhängig (Umfang von Datentypen usw).

Das stimmt so nicht. Es ist sehr wohl geregelt, man muß sich nur die plattformspezifische Implementierung genau ansehen.

... Ich schaue hin und weiss sofort: der Array ist 100 Zeichen
lang, erstes Byte liegt bei 0 und letztes Byte liegt bei 99.
Aber nur aufgrund impliziten Wissens.

Na gut, implizites Wissen um eine Programmiersprache ist doch Voraussetzung für eine halbwegs erfolgreiche VErwendung derselben, oder?

Ok aber darauf will ich jetzt nicht ewig herumreiten. Ich habe auch kein Problem mit dieser Definition von Feldern. Damit komme ich ganz gut klar. Was mir weniger gefällt ist eben nur, daß man keinen Startwert angeben kann.

Imho ist die Festlegung des Starwertes auf 0 einfacher, da man sich ja nur genau eine Regel merken muß.

Nicht jeder benutzt IDEs. Ich persönliche z. B. benutze keine IDE.
Da kann ich nur sagen: Selbst schuld.
Wenn Du Dir das Leben unnötig schwer machst, dann ist das Dein Problem. Schieb es dann aber nicht auf die Sprache wenn Dir dann irgendwas fehlt.

Was hat eine eventuell vorhandene IDE mit Sprachkonzepten zu tun? Mir fällt auf die Schnelle keine Sprache ein, die unbedingt eine IDE benötigen, sofern der Quelltext auch als Textdatei gespeichert werden kann.

Ich persönlich kann sowohl mit als auch ohne IDE recht gut leben. Einerseits finde ich auch, dass einem IDE'S das Leben zwar erleichtern können, andererseits verstehe ich Christian auch recht gut, weil verschiedene IDE-Systeme dazu neigen, den Programmierer zu bevormunden. Ausserdem verhindern sie oft, dass Programmierer die Sprache besser verstehen lernen.

Aber jedem das Seine und mir das Meine;-)

Abschließend möchte ich noch etwas anmerken, das bis jetzt so noch nicht richtig rübergekommen ist.
Ich habe persönlich keine wirkliche 'Lieblingssprache' (deshalb bin ich wahrscheinlich auch in keiner ein sog. Spezialist). Gute Programme kann man an sich in jeder Sprache schreiben, die ich bis jetzt verwendet habe (und das sind auch schon einige). Allerdings fällt mir auch keine Sprache ein, in der man nicht absoluten Bockmist zusammenschustern kann. So gut kann kein Sprachkonzept sein, dass es nicht von einem mehr oder weniger kranken Geist umgangen werden kann.

Wichtig ist nur, sich auf eine Sprache und deren Eigenheiten einzulassen. Will man in der einen Sprache alle Konzepte einer anderen Sprache umsetzen, dann ist man in der Regel auf dem falschen Weg.
Hier nur ein Beispiel: Als ich damals mit Perl begonnen habe, da habe ich vorher praktisch ausschließlich in C programmiert. Anfangs habe ich einige Konzepte, die ich in C verwendet habe, in Perl vermisst und versucht diese nachzubilden. Im Laufe der Zeit habe ich dann immer mehr von Perl verstanden, was dazu geführt hat, das meine Scripts immer mehr richtige Perl-Scripts waren und weniger C-Programme, die halt irgendwie in Perl umgesetzt sind.

Ähnliches erlebte ich auch, als ich zum ersten Mal von einem CAD-System zu einem anderen wechselte. Später, so nach dem dritten oder vierten, war es mir schon egal, welches Teil mir vorgesetzt wurde. Irgendwie kommt man zur Erkenntnis, dass der Satz 'Kennt man eines, kennt man alle' doch nicht so aus der Luft gegriffen ist;-)

Genauso verhält es sich auch mit den Programmiersprachen. Man sollte sich halt nur nicht in eine Sprache 'verlieben'.

Grüße
  Klaus

[MichaelB]

Hallo,

Meinens Wissens nach ist es auch unter vielen anderen Pascal-Dialekten so. Bei Turbo Pascal war die Längenangabe eine Byte-Variable. Daher auch nur 255 Zeichen. Manch andere verwenden dafür Integer und dann hat man schon deutlich mehr.
Weiter unten kritisierst Du die Implementierungsabhängigkeit von Datentypen bei C, bei Pascal ist das für Dich in Ordnung, oder wie?

Halber Punkt für Dich. Warum nur ein halber? Weil bei C es viel mehr ungeregelte Dinge gibt wie bei Pascal. Und das ist, was mich stört. Die Vielzahl an ungeregelten Dingen.

C wurde an sich dafür entwickelt, um Betriebssysteme schreiben zu können, ohne alles in Assembler zu machen, damit dieses Betriebssystem möglichst einfach auf eine neue Hardware portiert werden kann. Irgendwie ist imho C so ein Mittelding zwischen Assembler und Hochsprachen wie Pascal oder Fortran oder ähnlichem.

Ich weiß ja nicht ob Du mein Posting zu Ende gelesen hast. Aber sowas in der Art schrieb ich bereits. Nur halt kürzer und prägnanter.
Das Problem ist nur, daß viele Leute C nicht nur in dem Einsatzgebiet einsetzen wollen, für das die Sprache gut geeignet ist.

Da Betriebssystem-Funktionen in der Regel sehr oft aufgerufen werden macht es sinn, diese so performant wie möglich zu machen. Wenn nun aufwendige Prüfungen auch dann jedesmal gemacht, wenn in einem bestimmten Code-Abschnitt die Prüfbedingungen garantiert nie verletzt werden können, dann leidet die Performance darunter.

Unter Pascal kann ich diese Prüfungen abschalten (zum Beispiel wenn mein Code durchgetestet ist). Und das mit einem Schalter und ohne den Quelltext verändern zu müssen.

Ein weiteres Ziel bei der Entwicklung von C war, sie möglichst einfach zu gestalten, was die Core-Syntax betrifft, damit die Erstellung eines Compilers für eine neue Plattform so einfach wie möglich ist.

Das erklärt aber nicht die Unlogik in der Syntax (darauf bist Du ja clevererweise überhaupt nicht eingegangen).
Warum beispielsweise für das switsch-Konstrukt zwei Schlüsselworte benötigt werden und für das äquivalente in Pascal nur Eines bleibt mir unklar. Wenn man schon eine minimalistische Sprache haben will, warum leistet man sich dann solche Schnitzer?
Und heutzutage gibt es eigentlich keine Berechtigung mehr eine Sprache so aufzubauen, dass der Compiler einfach ist. Trotzdem hat man es mehrfach versäumt C entsprechend nachzubessern.

Alles was nicht direkt in der Sprache notwendig ist, wurde in die Bibliotheken verlagert.
Ausserdem, wozu soll ich denn File-Handling-Funktionen in eine Sprache einbauen, wenn das OS auf dem das Programm dann läuft vielleicht gar keine Dateien kennt?

Auch das ist durchaus positiv zu bewerten. Ich habe ja auch bereits geschrieben, daß dies seine Vorteile hat. Ich wiederhole mich aber gern: Nicht _alles_ ist an Pascal besser oder gut gelöst aber vieles besser gegenüber C.

Warum müssen Prozeduren einen Datentyp (void) zurückgeben?
Weil es in C so etwas wie Prozeduren gar nicht gibt. Es gibt nur Funktionen, die nichts (void) zurückliefern;-)
Warum kann man bei einer mit void deklarierten Funktion überhaupt ein Rückgabewert angeben ohne das der Compiler meckert?
Dann verwendest Du anscheinen keinen Ansi-Compiler.

Keine Ahnung. Ältere Compiler konnten das jedenfalls nicht. Das sie über die Jahrzehnte etwas verbessert haben, möchte ja wohl auch sein.

Der Operatorreihenfolge ist ungeschickt gewählt. Beispiel:
int a;
a=10;
--x=(++x)--;
Na gut, nicht alles was möglich ist, ist auch sinnvoll. Das von Dir gewählte Beispiel hätte ich nie und nimmer geschrieben.

Ähm. Das sollte war auch nicht zum verwenden gedacht sondern sollte nur aufzeigen, wie unlogisch in C die Operationsreihenfolge ist. Was einem (wie ich bereits schrieb) zu sehr vielen Klammersetzungen nötigt die dann der Übersichtlichkeit schaden.

Und apropos Operator: Ganz krank ist ja nun dieses = für eine Zuweisung und == für Vergleich. Ich möchte nicht wissen, wie oft Programmierer darüber geflucht haben wenn in vielen unbeabsichtigen Verwechslungsfällen der Compiler keine Fehlermeldung liefert. --> Krankes Konzept da nicht am Menschen orientiert.
Die meisten Compiler die ich kenne, geben eine Warning aus, wenn innerhalb von Bedingungen Zuweisungen erfolgen. Das aber nur so nebenbei.
Ich persönlich fluche eher, weil ich in Pascal bei jeder Zuweisung := verwenden muß, nur damit ich bei den, viel seltener benötigten, Vergleichen ein einfaches = verwenden kann.

Dieses := war aber auch damals in anderen Programmiersprachen gang und gäbe. Hier hat man mutwillig eine Änderung vorgenommen ohne Not.
Wenn man sich einmal eingearbeitet hat, dann ist dass ja auch nicht mehr das Problem. Beim Umstieg aber schon.
Und wegen der Tipparbeit ... ich denke mal, daß hast Du nicht ernsthaft gemeint.

Da gefällt mir das C-Konzept viel besser (genauso wie es anscheinend auch den Entwicklern von praktisch allen Sprachen, die C-ähnliche Syntax verwenden genug gefallen hat, um es zu übernehmen).

Programmiersprachen mit C ähnlicher Syntax richten sich ja üblicherweise auch an C Programmierer. Da wäre es fatal solch grundlegenden Sachen zu ändern.

Auch die Mehrfachverwendung von Schlüsselwörtern mit jeweils komplett unterschiedlicher Bedeutung macht es einem nicht gerade einfach (beispielsweise: static).
Da hast Du sicherlich recht, allerdings ist dieser Makel auch in vielen anderen Sprachen anzutreffen.

In Pascal fällt mir kein eklatantes Beispiel ein. Vielleicht kannst Du mir mal weiterhelfen.

Viele Dinge in C sind nicht geregelt und implementierungsabhängig (Umfang von Datentypen usw).
Das stimmt so nicht. Es ist sehr wohl geregelt, man muß sich nur die plattformspezifische Implementierung genau ansehen.

Ähm ... warum gibt es überhaupt plattformspezifische Implementierungen? Gut. C ist hardwarenah und wenn ich beispielsweise ein Betriebssystem für eine Plattform schreibe, macht es ja auch Sinn schon wegen der Optimierungsmöglichkeiten. Aber auch nur dann. Aber wenn, dann würde ich int nicht mal so und mal so machen sondern einfach Variablentypen verwenden speziell für 8Bit, 16Bit, 32Bit usw. Dann weiß ich wenigstens, woran ich bin.

... Ich schaue hin und weiss sofort: der Array ist 100 Zeichen
lang, erstes Byte liegt bei 0 und letztes Byte liegt bei 99.
Aber nur aufgrund impliziten Wissens.
Na gut, implizites Wissen um eine Programmiersprache ist doch Voraussetzung für eine halbwegs erfolgreiche VErwendung derselben, oder?

Schon. Aber nicht für das lernen.

Ok aber darauf will ich jetzt nicht ewig herumreiten. Ich habe auch kein Problem mit dieser Definition von Feldern. Damit komme ich ganz gut klar. Was mir weniger gefällt ist eben nur, daß man keinen Startwert angeben kann.
Imho ist die Festlegung des Starwertes auf 0 einfacher, da man sich ja nur genau eine Regel merken muß.

Wie schon mal gesagt. Nicht immer braucht man ein Feld mit dem Startwert 0. Und dann ist es einfach eine Fehlerquelle. Pascal gibt mir 'ne Fehlermeldung aus, wenn ich durch irgendwas den Array-Bereich verlasse. In C ist es dann ein schwer zu findener Bug.

Nicht jeder benutzt IDEs. Ich persönliche z. B. benutze keine IDE.
Da kann ich nur sagen: Selbst schuld.
Wenn Du Dir das Leben unnötig schwer machst, dann ist das Dein Problem. Schieb es dann aber nicht auf die Sprache wenn Dir dann irgendwas fehlt.
Was hat eine eventuell vorhandene IDE mit Sprachkonzepten zu tun? Mir fällt auf die Schnelle keine Sprache ein, die unbedingt eine IDE benötigen, sofern der Quelltext auch als Textdatei gespeichert werden kann.

Aber der Umgang mit der Sprache wird deutlich vereinfacht und man kann Dinge machen, die sonst von der Sprache nicht unterstützt werden müssen (blödes Beispiel: Refactoring).
Ich kann mir auch sinnvollere Sichten auf die Sprache legen. Klassiches Beispiel sind GUI-Designer.
Das alles vereinfacht mir den Umgang mit der Sprache ohne das die Sprache selbst etwas dazu beitragen muss.

Ich persönlich kann sowohl mit als auch ohne IDE recht gut leben. Einerseits finde ich auch, dass einem IDE'S das Leben zwar erleichtern können, andererseits verstehe ich Christian auch recht gut, weil verschiedene IDE-Systeme dazu neigen, den Programmierer zu bevormunden.

Wenn sich das nicht abschalten läßt, hast Du die falsche IDE :-)

Ausserdem verhindern sie oft, dass Programmierer die Sprache besser verstehen lernen.

Sicher. Man kommt nicht umhin sich mit einer Sprache zu beschäftigen. Aber wenn man das dann drauf hat, warum sollte man sich das Leben dann nicht erleichtern?

Aber jedem das Seine und mir das Meine;-)

:-) Gute Einstellung.

Abschließend möchte ich noch etwas anmerken, das bis jetzt so noch nicht richtig rübergekommen ist.
Ich habe persönlich keine wirkliche 'Lieblingssprache' (deshalb bin ich wahrscheinlich auch in keiner ein sog. Spezialist). Gute Programme kann man an sich in jeder Sprache schreiben, die ich bis jetzt verwendet habe (und das sind auch schon einige). Allerdings fällt mir auch keine Sprache ein, in der man nicht absoluten Bockmist zusammenschustern kann. So gut kann kein Sprachkonzept sein, dass es nicht von einem mehr oder weniger kranken Geist umgangen werden kann.

Stimmt. Aber C macht es einem in vielen Fällen besonders leicht.

Wichtig ist nur, sich auf eine Sprache und deren Eigenheiten einzulassen. Will man in der einen Sprache alle Konzepte einer anderen Sprache umsetzen, dann ist man in der Regel auf dem falschen Weg.

Es geht nicht darum das Konzept einer Sprache auf eine andere zu übertragen. Mir genügte es, wenn C ein logisch Konzept hätte!

Hier nur ein Beispiel: Als ich damals mit Perl begonnen habe, da habe ich vorher praktisch ausschließlich in C programmiert. Anfangs habe ich einige Konzepte, die ich in C verwendet habe, in Perl vermisst und versucht diese nachzubilden. Im Laufe der Zeit habe ich dann immer mehr von Perl verstanden, was dazu geführt hat, das meine Scripts immer mehr richtige Perl-Scripts waren und weniger C-Programme, die halt irgendwie in Perl umgesetzt sind.

Da ist viel Wahres dran.
Aber C macht einen gerade in der Einarbeitung das Leben schwer. Denk nur mal an den Zeigerkram mit Referenzierung und Dereferenzierung. Wieviele Anfänger wie oft darüber gestolpert sind, möchte ich nicht wissen (und selbst den Profis passieren damit imemr wieder Fehler). Vielleicht liegt es an meinem Unvermögen, aber ich habe lange gebraucht um das zu kapieren.
Das Zeigerkonzept von Pascal habe ich dagegen recht schnell begriffen, obwohl ich davor nichtmal wußte was ein Zeiger ist.
Ebenso das Zeigerkonzept von Java was ja nun wiederum völlig verschieden ist zu Pascal oder C habe ich auch schnell verstanden.

Genauso verhält es sich auch mit den Programmiersprachen. Man sollte sich halt nur nicht in eine Sprache 'verlieben'.

Ich bin nicht in Pascal verliebt. Sonst würde ich wahrscheinlich immer noch damit programmieren. Was mir eben nur aufgefallen ist das trotz Pascal älter ist mit C eine Sprache geschaffen wurde die gegenüber Pascal viele Nachteile hat. Und das an vielen Stellen völlig unnötig.

Gruß
   MichaelB

[Christian Kruse]

Hallo MichaelB,

Ich koennte mir vorstellen, dass das ein
wenig mit dem Alter der Sprache zusammenhaengt.
Naja. Objective-C und C++ sind etwa zur selben Zeit entstanden.

Etwa drei Jahre Unterschied in den Release-Daten.

Grüße,
 CK

[MichaelB]

Hallo CK,

Ich koennte mir vorstellen, dass das ein
wenig mit dem Alter der Sprache zusammenhaengt.
Naja. Objective-C und C++ sind etwa zur selben Zeit entstanden.
Etwa drei Jahre Unterschied in den Release-Daten.

Du magst recht haben was die (mehr oder weniger) offizielle Veröffentlichung angeht. Fakt ist, daß es die Urform von Objective-C schon in den frühen achtziger Jahren gab die dann weiterentwickelt wurde. Meistens ist das ja die Entwicklung einer Programmiersprache ein längerfristiger Prozess der sich über mehrere Jahre erstreckt. Deshalb ist es schwierig zu sagen, was früher oder später entstanden ist.

Ungefähr zur selben Zeit trifft es meiner Meinung nach ganz gut. Ist aber auch nicht so sehr relevant. Keiner hat ja vom anderen direkt abschaut und sich dann gefragt, wie kann man das verbessern sondern schon die Herangehensweise war völlig unterschiedlich.

Übrigens. Wenn es interessiert: http://www.levenez.com/lang/history.html

Gruß
  MichaelB

[Kopfwunde]

Hallo

Gibt es irgendwo eine "C-Bibel" auf deutsch ?

Falls du lieber gleich mit C++ anfangen willst, kann ich dir http://www.cpp-entwicklung.de/cpplinux/cpp_main/cpp_main.html empfehlen. Es heißt zwar "C++-Entwicklung mit Linux", ist aber eigentlich ziemlich allgemein gehalten. Leider ist es teilweise schon leicht veraltet.

Gruß
Kopfwunde

[Eternius]

hallo

Also ich denke ich werde mir mal C anschauen (ist da ein Unterschied zu C++? dachte C ist die Abkürzung dafür)

Es war einmal die Sprache A, auf die folgte die Sprache B, danach der Nachfolger hiess C (bis jetzt auch noch für Frauen logisch). Dann kam der Verrückte auf die idee und benannte den nachfolger von C mit C++ weil der operator ++ in c für die erhöhung einer variablen steht (grob zumindest) also ist C++==D.
dann kam wieder son lustmolch und bastelte C# (sharp) was, wenn man genau hinguckt aus 4 mal + besteht:
++
++

ist gleich #
also C++++==E

oder watt.

gruss

[GONZO]

Hallo Eternius,

leider liegst du nicht ganz richtig.

Siehe den drittletzten (größeren) Absatz hier:
http://www.wall.org/~larry/pm.html

Es gab erst B (erster Buchstabe von BCPL, seinem Vorgänger),
dann gab es C (zweiter Buchstabe) und dann hat Perl sich
die letzten beiden Buchstaben von BCPL geklaut.

Vielleicht ist das auch die Perl Sicht der Dinge,
aber zumindest A gab es nie.

CYa
GONZO

[MichaelB]

Hallo,

aber zumindest A gab es nie.

Das kann man so nicht sagen: http://www.htwm.de/~rjentsch/c.html
:-)))))))))))))

Gruß
  MichaelB

[Jürgen Ulmschneider]

Und nochmal Hallo:)

Also ich möchte éntweder eine eigenständige EXE-Datei haben, oder eben sowas wie der Weaverslave, eine EXE-Datei mit einigen XML-Zusatzdateien usw.
Also irgendwas, wo man nicht extra JVM oder etwas anderes zusätliches Installieren muss um das Programm auszuführen.

Eigentlich reicht es, wenn es unter Windows läft, vielleicht noch unter Linux, aber Mac ist nicht so wichtig.
Hat eh fast keiner, und momentan verwende ich die Programme ja eh nur selbst...

Das Posting von michelB war nicht eindeutig.
Muss ich die JVM für ein einfaches Programm installier haben oder nicht ?
Kann ich das nicht irgendwie in Programmcode compilen lassen oder sowas ?

Danke, Jürgen.

[MichaelB]

Hallo,

Das Posting von michelB war nicht eindeutig.
Muss ich die JVM für ein einfaches Programm installier haben oder nicht ?

Mgölichst schon. Aber wenn Du das Programm eh vorwiegend für Dich verwenden willst, was spricht dann dagegen?

Kann ich das nicht irgendwie in Programmcode compilen lassen oder sowas ?

Soweit ich weiß bietet die GCC die Möglichkeit zumindest unter Linux native Programme zu erzeugen, die keine weitere VM brauchen (auch wenn einige API-Teile noch davon ausgeschlossen sind).
http://gcc.gnu.org/java/

Unter Windows gibt es auch die Möglichkeit native-Code (sprich EXE-Dateien) zu erzeugen. Allerdings sind dies meist kostenpflichte Programme. Allerdings stellt sich die Frage nach dem Sinn. Geschwindigkeitsvorteile sind kaum zu erwartet. Bleibt also nur vereinfachte Weitergabe des Programms, da keine extra JavaVM benötigt wird.
http://www.excelsior-usa.com/jetde.html

Darüber hinaus gibt es die Möglichkeit Dein Java-Programm und die JavaVM in einer EXE-Datei zu bündeln z.B. mit
http://www.ej-technologies.com/products/exe4j/overview.html

Gruß
   MichaelB

[Fabian Transchel]

Hallo,

Das Posting von michelB war nicht eindeutig.
Muss ich die JVM für ein einfaches Programm installier haben oder nicht ?
Mgölichst schon.

Entschuldige, was für eine Scheiß-Antwort.

Java läuft nicht besser oder so, wenn man 'ne VM hat. Nein, Java-Bytecode läuft sonst garnicht.

Grüße aus Barsinghausen,
Fabian

[MichaelB]

Hallo,

Das Posting von michelB war nicht eindeutig.
Muss ich die JVM für ein einfaches Programm installier haben oder nicht ?
Mgölichst schon.
Entschuldige, was für eine Scheiß-Antwort.

Ich wollte damit zum Ausdruck bringen, daß man zwar nicht in jeder Situation (beispielsweise wenn man einen Native-Code-Compiler verwendet) eine installierte Java-VM braucht aber es dennoch die (aus meiner Sicht) beste Lösung ist wenn man eine Java-VM verwendet.
Erstens bleibt dabei die Plattformunabhängigkeit erhalten und zweitens ist nicht sichergestellt, daß die native-code-Compiler den vollen Funktionsumfang von Java (also ich meine der API) unterstützen.

Java läuft nicht besser oder so, wenn man 'ne VM hat. Nein, Java-Bytecode läuft sonst garnicht.

Wie gesagt. Wenn man native-code erzeugt dann ja.
Aber das alles was Du kritisierst geht eigentlich aus dem weiteren Verlauf meines Postings hervor. Vielleicht solltest Du nächstes Mal bis zum Ende lesen.

Gruß
   MichaelB

[Fabian Transchel]

Hallo Michael,

Muss ich die JVM für ein einfaches Programm installier haben oder nicht ?
Mgölichst schon.
Entschuldige, was für eine Scheiß-Antwort.
Ich wollte damit zum Ausdruck bringen, daß man zwar nicht in jeder Situation (beispielsweise wenn man einen Native-Code-Compiler verwendet) eine installierte Java-VM braucht aber es dennoch die (aus meiner Sicht) beste Lösung ist wenn man eine Java-VM verwendet.
Erstens bleibt dabei die Plattformunabhängigkeit erhalten und zweitens ist nicht sichergestellt, daß die native-code-Compiler den vollen Funktionsumfang von Java (also ich meine der API) unterstützen.

Java läuft nicht besser oder so, wenn man 'ne VM hat. Nein, Java-Bytecode läuft sonst garnicht.
Wie gesagt. Wenn man native-code erzeugt dann ja.

Genau das sagst du aber an der Stelle nicht.

Aber das alles was Du kritisierst geht eigentlich aus dem weiteren Verlauf meines Postings hervor. Vielleicht solltest Du nächstes Mal bis zum Ende lesen.

Ich habe bis zum Ende gelesen, ganz einfach, weil mich immer bis zum Ende lese. Wenn du auf die Frage "Muss ich die JVM für ein einfaches Programm installier haben oder nicht?" mit "möglichst schon" antwortest ist das meiner Meinung nach völlig sinnfrei, weil du das (an der Stelle) nicht näher ausführst. Ich stimme mit dem, was du danach schreibst völlig überein, auch das steht in meinem Post, das Problem, das ich sehe und du womöglich im Moment nicht, ist einfach dass wir hier mit jemandem diskutieren, der keine Ahnung von Java hat[1] und deswegen eine exakte Erklärung verdient, wenn er wissen möchte, was auf ihn zukommt. Es wird für ihn IMO einfach nicht deutlich genug, was dieses "möglichst schon" konkret bedeutet. Für die Wortwahl möchte ich mich entschuldigen, ich hoffe du nimmst es mir nicht sehr übel und verstehst jetzt besser, was ich ausdrücken wollte.

[1] Wofür ihm kein Vorwurf zu machen ist, deswegen fragt er ja.

Grüße aus Barsinghausen,
Fabian

[MichaelB]

Hallo Fabian,

Muss ich die JVM für ein einfaches Programm installier haben oder nicht ?
Mgölichst schon.
Entschuldige, was für eine Scheiß-Antwort.
Ich wollte damit zum Ausdruck bringen, daß man zwar nicht in jeder Situation (beispielsweise wenn man einen Native-Code-Compiler verwendet) eine installierte Java-VM braucht aber es dennoch die (aus meiner Sicht) beste Lösung ist wenn man eine Java-VM verwendet.
Erstens bleibt dabei die Plattformunabhängigkeit erhalten und zweitens ist nicht sichergestellt, daß die native-code-Compiler den vollen Funktionsumfang von Java (also ich meine der API) unterstützen.

Java läuft nicht besser oder so, wenn man 'ne VM hat. Nein, Java-Bytecode läuft sonst garnicht.
Wie gesagt. Wenn man native-code erzeugt dann ja.

Genau das sagst du aber an der Stelle nicht.

Weil das schon Detailfragen sind. Wenn man mit Java anfängt dann ist es erstmal wichtig, dass man überhaupt irgendwie seine Programme zu Lernzwecken lauffähig bekommt. Egal ob nun mit Java-VM oder ohne. Die Frage zielt also eher darauf ab, ob generell Standalone-Java-Applikationen möglich sind und das ist der Fall.
Wie genau das Zusammenhängt ist aber doch im Augenblick noch gar nicht wichtig, weil ja erstmal die Entscheidung für eine Programmiersprache getroffen werden muss. Danach kann man sich dann mit Details beschäftigen.

Aber das alles was Du kritisierst geht eigentlich aus dem weiteren Verlauf meines Postings hervor. Vielleicht solltest Du nächstes Mal bis zum Ende lesen.
Ich habe bis zum Ende gelesen, ganz einfach, weil mich immer bis zum Ende lese. Wenn du auf die Frage "Muss ich die JVM für ein einfaches Programm installier haben oder nicht?" mit "möglichst schon" antwortest ist das meiner Meinung nach völlig sinnfrei, weil du das (an der Stelle) nicht näher ausführst.

Wie gesagt. Das geht aus dem weiteren Verlauf des Postings hervor (wenn dem Fragesteller dabei irgendwas unklar bleibt ist es auch seine Sache nachzufragen).

Ich stimme mit dem, was du danach schreibst völlig überein, auch das steht in meinem Post, das Problem, das ich sehe und du womöglich im Moment nicht, ist einfach dass wir hier mit jemandem diskutieren, der keine Ahnung von Java hat[1] und deswegen eine exakte Erklärung verdient, wenn er wissen möchte, was auf ihn zukommt.

Ist halt nur die Frage, wie weit man ins Detail geht. Zuviel Details können auch verwirren. Ich gebe zu, dass meine Formulierung etwas ungeschickt war.
Aber wie gesagt: Wenn dem Fragesteller etwas unklar bleibt ist es an ihm nachzufragen.
Es war ja "nur" eine ungeschickte Formulierung und keine Falschinformation.

Für die Wortwahl möchte ich mich entschuldigen, ich hoffe du nimmst es mir nicht sehr übel und verstehst jetzt besser, was ich ausdrücken wollte.

Übel nehmen tue ich es Dir nicht. Ich kann schon nachvollziehen, was Du meinst. Kein Problem.

Falls Du das heute noch liest, wünsch ich Dir eine Gute Nacht
Grüße
    MichaelB

[Christian Seiler]

Hallo MichaelB,

Kann ich das nicht irgendwie in Programmcode compilen lassen oder sowas ?
Soweit ich weiß bietet die GCC die Möglichkeit zumindest unter Linux native Programme zu erzeugen, die keine weitere VM brauchen (auch wenn einige API-Teile noch davon ausgeschlossen sind).
http://gcc.gnu.org/java/

Hmmm, ich sollte Threads wirklich vollständig lesen, bevor ich etwas poste... ([pref:t=78632&m=454976])

Viele Grüße,
Christian

[Fabian Transchel]

Halo Christian,

Kann ich das nicht irgendwie in Programmcode compilen lassen oder sowas ?
Soweit ich weiß bietet die GCC die Möglichkeit zumindest unter Linux native Programme zu erzeugen, die keine weitere VM brauchen (auch wenn einige API-Teile noch davon ausgeschlossen sind).
http://gcc.gnu.org/java/

Hmmm, ich sollte Threads wirklich vollständig lesen, bevor ich etwas poste... ([pref:t=78632&m=454976])

Jop. Wollte dich auch schon grade hierher verweisen, habe dann aber nochmal geschaut :)

Ich hoffe doch, dass es für den Ausgangsposter jetzt deutlich geworden ist, was mit Java hinsichtlich Einsetzbarkeit geht und was nicht.

Grüße aus Barsinghausen,
Fabian

[nobody]

ich möchte ein auto kaufen.

welches ist das richtige?

es soll 10 tonnen sand transportieren können,
100 leuten platz bieten,
jedes formel1 rennen gewinnen,
in meine klein garage passen,
und nur 3 liter verbrauchen.

[Fabian Transchel]

Tach Troll,

ich möchte ein auto kaufen.

Das ist lobenswert. Wenn es ein deutscher Hersteller ist, hilfst du sogar ein bisschen unserer Konjuktur.

welches ist das richtige?

es soll 10 tonnen sand transportieren können,
100 leuten platz bieten,
jedes formel1 rennen gewinnen,
in meine klein garage passen,
und nur 3 liter verbrauchen.

Tja, wie ich das sehe, entweder du nimmst das Raumschiff Enterprise (mehr als drei Liter Antimaterie brauchst du nicht, denke ich), oder aber du baust dir 'nen IE um ;-)

Nix für ungut.

Grüße aus Barsinghausen,
Fabian

[MichaelB]

Hallo,

Tja, wie ich das sehe, entweder du nimmst das Raumschiff Enterprise (mehr als drei Liter Antimaterie brauchst du nicht, denke ich),

Sollte man echt mal nachrechnen wieviel Energie man herausbekommt und ob die ausreicht, um ein Raumschiff mit der Masse der Enterprise wirklich ausreichend zu beschleunigen.
Er meinte sicherlich 3 Liter auf 100km. Das sollte in der Tat locker reichen.

Gruß
  MichaelB

[Fabian Transchel]

Hallo Michael,

Tja, wie ich das sehe, entweder du nimmst das Raumschiff Enterprise (mehr als drei Liter Antimaterie brauchst du nicht, denke ich),
Sollte man echt mal nachrechnen wieviel Energie man herausbekommt und ob die ausreicht, um ein Raumschiff mit der Masse der Enterprise wirklich ausreichend zu beschleunigen.

Er meinte sicherlich 3 Liter auf 100km. Das sollte in der Tat locker reichen.

Mal sehen. Bei Direktumwandlung von Materie in Energie gilt E = mc². Für drei Liter Antimaterie (wir gehen der Einfachheit halber mal von Anti-Wasserstoff aus) erhalten wir eine Antimaterie-Masse von 2,69 g (für eine Normaldichte von 0,0899 kg/m³ für Wasserstoff). Die daraus zu gewinnene Energie beträgt also 2,905 * 10^10 Joule. Wir gehen mal davon aus, dass die gesamte Energie in den Antrieb gesteckt wird, daher erhalten wir mit E = mc² (diesmal nach c auflösen) eine Maximalgeschwindigkeit von 173 m/s [1], wenn man die Energie sofort komplett in kinetische Energie umwandelt und alle denkbaren Reibungsverluste ausser Acht lässt. Das ist relativ wenig, wenn man bedenkt mit welchen fiktiven Geschindigkeiten Kirk sonst so 'rumreist, allerdings relativ viel, wenn man beachtet, dass wir mit dem 193.000-Tonnen-Viech nur mal Brötchen holen wollen :)

[1] Masse der ersten USS Enterprise NCC 1701: 193.000 Tonnen. Für die Rechnung keine Garantie auf Korrektheit. Physiker dürfen gerne Widerspruch erheben, solange sie mir dann den Fehler erklären :)

Grüße aus Barsinghausen,
Fabian

[MichaelB]

Hallo Fabian,

Mal sehen. Bei Direktumwandlung von Materie in Energie gilt E = mc². Für drei Liter Antimaterie (wir gehen der Einfachheit halber mal von Anti-Wasserstoff aus) erhalten wir eine Antimaterie-Masse von 2,69 g (für eine Normaldichte von 0,0899 kg/m³ für Wasserstoff). Die daraus zu gewinnene Energie beträgt also 2,905 * 10^10 Joule. Wir gehen mal davon aus, dass die gesamte Energie in den Antrieb gesteckt wird, daher erhalten wir mit E = mc² (diesmal nach c auflösen)

Nicht das es die Größenordnung Deines Ergebnisses sehr verändern würde aber ist nicht die kinetische Energie E=m*v²/2 ?

Gruß
   MichaelB

[Fabian Transchel]

»» Hallo Fabian,

Mal sehen. Bei Direktumwandlung von Materie in Energie gilt E = mc². Für drei Liter Antimaterie (wir gehen der Einfachheit halber mal von Anti-Wasserstoff aus) erhalten wir eine Antimaterie-Masse von 2,69 g (für eine Normaldichte von 0,0899 kg/m³ für Wasserstoff). Die daraus zu gewinnene Energie beträgt also 2,905 * 10^10 Joule. Wir gehen mal davon aus, dass die gesamte Energie in den Antrieb gesteckt wird, daher erhalten wir mit E = mc² (diesmal nach c auflösen)
Nicht das es die Größenordnung Deines Ergebnisses sehr verändern würde aber ist nicht die kinetische Energie E=m*v²/2 ?

Ja und nein. 1/2mv² ist die Formel der klassischen Mechanik, E=mc² die entsprechende der Relativitätstheorie. Der Unterschied dabei kommt erst ungefähr bei v > 0,3c zum Tragen, dann jedoch wird deutlich, dass es für die Geschwindigkeit den Grenzwert c gibt, was in der klassischen Mechanik nicht bedacht ist. Du hast Recht, dass wir in relativistisch relevante Größenordnungen von v nicht kommen, daher wäre es eigentlich angebracht, den letzten Wert für die Geschwindigkeit nach klassischer Methode zu errechnen. Deutlich wird denke ich dennoch, dass das Schiff nicht allzu schnell wird, ganz einfach weil die Masse zum Brötchenholen ohnehin viel zu riesig ist. Und ja, in 'ne normale Garage passt's auch nicht ;-)

Grüße aus Barsinghausen,
Fabian

[MichaelB]

Hallo Fabian,

Ja und nein. 1/2mv² ist die Formel der klassischen Mechanik, E=mc² die entsprechende der Relativitätstheorie.

Soweit ich mich an meine Schulzeit richtig erinnere hat die Einsteinformel E=mc² und E=1/2mv² nicht all zu viel miteinander zu tun. Die Einsteinformel repräsentiert ja im Prinzip die Äquivalenz von Masse und Energie. Sprich wenn ich ein Körper der Masse m in Energie zerstrahle bekomme ich dafür E.
E=1/2mv² ist ja die kinetische Energie. Sprich: Ein Körper der Masse m der sich mit der Geschwindigkeit v bewegt hat eine kinetische Energie von E.

Das sind für mich zwei völlig verschiedene Dinge.

Deutlich wird denke ich dennoch, dass das Schiff nicht allzu schnell wird, ganz einfach weil die Masse zum Brötchenholen ohnehin viel zu riesig ist. Und ja, in 'ne normale Garage passt's auch nicht ;-)

Bei dem Wetter würde ich ohnehin das Fahrrad zum Brötchen holen bevorzugen. Wäre auch etwas besser in der Energiebilanz. Mal ganz abgesehen davon, dass vor unserer Bäckerei der Parkplatz für eine Enterprise recht knapp bemessen ist. :-)

Gruß
   MichaelB

[Christian Seiler]

Hallo Michael,

Soweit ich mich an meine Schulzeit richtig erinnere hat die Einsteinformel E=mc² und E=1/2mv² nicht all zu viel miteinander zu tun. Die Einsteinformel repräsentiert ja im Prinzip die Äquivalenz von Masse und Energie. Sprich wenn ich ein Körper der Masse m in Energie zerstrahle bekomme ich dafür E.
E=1/2mv² ist ja die kinetische Energie. Sprich: Ein Körper der Masse m der sich mit der Geschwindigkeit v bewegt hat eine kinetische Energie von E.

Das sind für mich zwei völlig verschiedene Dinge.

Es gibt allerdings noch eine weitere - relativistische - Formel:

m0
m =  -----------------------
     _      ----------------
      \    /            v
       \  /  1    -    ---
        /              c

(Hmmm, in LaTeX geht das einfacher ;))

Diese gibt die Masse in Abhängigkeit von der Geschwindigkeit an. m0 ist hierbei die Ruhemasse bei v = 0.

Allerdings: Die Formel ist hier auch nicht anwendbar, wir verwandeln ja nicht die Energie wieder in Masse, sondern beschleunigen die Masse mit dieser Energie. Daher ist 1/2mv² durchaus anwendbar, allerdings muss man, wenn man relativistisch rechnen will, für m die relativistische Masse.

D.h. wenn wir die 2.905 * 10^10 J haben, dann müssten wir folgendes Rechnen:

W = 1/2mv² = 1/2*m0v²/(sqrt(1-v/c))

2W/m0 = v²/(*sqrt(1-v/c))

v²/sqrt(1-v/c) = 2W/m0
sqrt(v/(1-v/c)) = 2W/m0
v/(1-v/c) = (2W/m0)²
v = (2W/m0)²*(1-v/c)
v = (2W/m0)²-(2W/m0)²*v/c
v + (2W/m0)²*v/c = (2W/m0)²
v ( 1 + (2W/m0)²/c ) = (2W/m0)²
v = (2W/m0)² / (1+(2W/m0)²/c)

Und das sind bei W = 2,905*10^10 J und c = 3 * 10^8 m/s und m0 = 193 * 10^6 kg:

(2W/m0)² = 3.37561e+21 J²/kg² => v = 299999999.99997 m/s.

Das wären also 99.999999999991% der Lichtgeschwindigkeit (ich bin von 3*10^8m/s ausgegangen, ich war zu faul, mir den genauen Wert irgendwo herauszukramen). Wir sehen: Mit 3 Litern Antimaterie kann man eine Menge anstellen. :)

Viele Grüße,
Christian

[Christian Seiler]

Hallo nochmal,

v²/sqrt(1-v/c) = 2W/m0
sqrt(v/(1-v/c)) = 2W/m0

d'oh.... ich Depp...

sqrt(v^4/(1-v/c)) = 2W/m0
v^4/(1-v/c) = (2W/m0)²
v^4 = (2W/m0)²*(1-v/c)
v^4 = (2W/m0)²-(2W/m0)²*v/c
v^4 + (2W/m0)²*v/c = (2W/m0)²

Das gäabe dann eine Gleichung vierten Grades:

• (2W/m0)²*v - (2W/m0)²*c+c*v^4 = 0

Und diese lässt sich dann warsch. nur Näherungsweise lösen. (oder über ewig komplizierte Lösungswege...)

(2W/m0)² = 3.37561e+21 J²/kg² => v = 299999999.99997 m/s.

Jargl. Ich sollte wirklich nicht auf den KDE Taschenrechner vertrauen... Also:

(2W/m0)² = 90622,83551 J²/kg²

Hmmm, und mein TR will mir auf die Schnelle leider keine Lösung für obige Gleichung ausspucken. :(

Viele Grüße,
Christian

[MichaelB]

Hallo Chrisitian,

v²/sqrt(1-v/c) = 2W/m0
sqrt(v/(1-v/c)) = 2W/m0
d'oh.... ich Depp...

Ah. Ok. Dann hat sich mein anderes Posting gerade erledigt :-)

sqrt(v^4/(1-v/c)) = 2W/m0
v^4/(1-v/c) = (2W/m0)²
v^4 = (2W/m0)²*(1-v/c)
v^4 = (2W/m0)²-(2W/m0)²*v/c
v^4 + (2W/m0)²*v/c = (2W/m0)²

Jo. Darauf kam ich dann nämlich auch.

Hmmm, und mein TR will mir auf die Schnelle leider keine Lösung für obige Gleichung ausspucken. :(

Kann v=90595.5m/s ungefähr hinhauen?

Gruß
  MichaelB

[Fabian Transchel]

Hallo nochmal Christian,

Das wären also 99.999999999991% der Lichtgeschwindigkeit (ich bin von 3*10^8m/s ausgegangen, ich war zu faul, mir den genauen Wert irgendwo herauszukramen). Wir sehen: Mit 3 Litern Antimaterie kann man eine Menge anstellen. :)

Damit wäre ich nachher dann auch gekommen, allerdings um für die andere Seite zu argumentieren.

Deine Prozentzal der erreichbaren Geschwindigkeit ist um genau so viel ungenau, wie du (oder dein Rechner) gerundet hast. Du hast hiermit eindrucksvoll nachgewiesen, dass E = mc² in der von mir geschilderten Weise Gültigkeit hat, denn du hast genau das getan, was Einstein auch gemacht hat, nämlich die klassische Formel 1/2mv² unter relativistischen Gesichtspunkten zu sehen. Damit hast du dich elegant selbst widerlegt :)

Grüße aus Barsinghausen,
Fabian

[Christian Seiler]

Hallo Fabian,

Du hast hiermit eindrucksvoll nachgewiesen, dass E = mc² in der von mir geschilderten Weise Gültigkeit hat,

Nö. Ich war nur zu blöd, die Terme richtig umzuformen. (grmbl)

Viele Grüße,
Christian

[MichaelB]

Hallo Christian,

Es gibt allerdings noch eine weitere - relativistische - Formel:

m0
m =  -----------------------
     _      ----------------
      \    /            v
       \  /  1    -    ---
        /              c

Ok. Da kommen wir der Sache schon näher

(Hmmm, in LaTeX geht das einfacher ;))

:-)

Diese gibt die Masse in Abhängigkeit von der Geschwindigkeit an. m0 ist hierbei die Ruhemasse bei v = 0.

Allerdings: Die Formel ist hier auch nicht anwendbar, wir verwandeln ja nicht die Energie wieder in Masse, sondern beschleunigen die Masse mit dieser Energie. Daher ist 1/2mv² durchaus anwendbar, allerdings muss man, wenn man relativistisch rechnen will, für m die relativistische Masse.

Da bin ich ja gespannt.

W = 1/2mv² = 1/2*m0v²/(sqrt(1-v/c))

2W/m0 = v²/(*sqrt(1-v/c))

v²/sqrt(1-v/c) = 2W/m0

Ok. Bis hier her ists klar.

sqrt(v/(1-v/c)) = 2W/m0

Darf man das v wirklich einfach mit in die Wurzel nehmen.
Müsste es wenn dann nicht eher:
sqrt(v^4/(1-v/c)) = 2W/m0
heißen ?

v/(1-v/c) = (2W/m0)²
v = (2W/m0)²*(1-v/c)
v = (2W/m0)²-(2W/m0)²*v/c
v + (2W/m0)²*v/c = (2W/m0)²
v ( 1 + (2W/m0)²/c ) = (2W/m0)²
v = (2W/m0)² / (1+(2W/m0)²/c)

Gruß
  MichaelB

[Christian Seiler]

Hi nochmal,

So, jetzt habe ich etwas getan, was ich hätte von Anfang an tun sollen, ich hab's nochmal nachgeschlagen. Ich sollte so etwas wirklich nicht versuchen, aus dem Kopf heraus zu rekonstruieren, da kommt wirklich nur 100%iger Müll raus (alle meine vorigen Postings bitte *IGNORIEREN*, das ist wirklich physikalisch gesehen absoluter Käse, ich schäme mich ja schon wirklich dafür *argh*).

1. Dazu:

Es gibt allerdings noch eine weitere - relativistische - Formel:

m0
m =  -----------------------
     _      ----------------
      \    /            v
       \  /  1    -    ---
        /              c

Urgs. Das ist so falsch; richtig müsste es heißen:

m = m0 / sqrt(1-v²/c²)

2. Dazu:

Daher ist 1/2mv² durchaus anwendbar,

Fabian hatte insofern von Anfang an Recht, dass 1/2mv² nicht anwendbar ist. Allerdings ist mir sein Rechenweg immer noch unklar.

In meinem Physikbuch steht nun folgendes:

Ein ruhendes Objekt hat die Ruheenergie W0 = m0 * c²

Ein sich bewegendes Objekt hat die Gesamtenergie W = m * c² mit m = m0/sqrt(1-v²/c²).

Folglich muss die Bewegungsenergie die Differenz beider Energien sein.

Um jetzt die kinetische Energie der Enterprise herauszubekommen, müssen wir zuerst die Ruheenergie berechnen:

W0 = m0 * c² = 193*10^6 kg * (3*10^8 m/s)² = 1,737*10^25 J

Nun addieren wir die kinetische Energie von 2,905 * 10^10 J, die Fabian berechnet hat. Die Gesamtenergie der sich bewegenden Enterprise entspricht also 1,737*10^25 J + 2,905 * 10^10 J. Dieser Term ist äußerst "doof". Jeder Taschenrechner rundet nämlich vorher.

Nun gilt:

W = m*c² => m = W/c²

Daher ist die neue Masse:

m = (1,737*10^25 J + 2,905 * 10^10 J)/(3*10^8)² = 193*10^6kg + 3,23 * 10^-7 kg

Nun gilt:

m = m0/sqrt(1-v²/c²)

Daher:

sqrt(1-v²/c²) = m0/m

1-v²/c² = m0² / m²

Folglich gilt also:

1-v²/c² = (193*10^6kg)²/(193*10^6kg + 3,23 * 10^-7kg)²

-v²/c² = (193*10^6kg)²/(193*10^6kg + 3,23 * 10^-7kg)² - 1
v²/c² = 1 - (193*10^6kg)²/(193*10^6kg + 3,23 * 10^-7kg)²
v² = (1 - (193*10^6kg)²/(193*10^6kg + 3,23 * 10^-7kg)²)* c²

Der Taschenrechner spuckt mir da als Ergebnis (algebraisch gerechnet und nur das Endergebnis approximiert) 17,35636838 m/s aus.

Wenn ich das klassich rechne mit Wkin = 1/2 m0v², dann komme ich auf folgendes Ergebnis: 17,35039681 m/s. Also immerhin ein Fehler von ca. 0,03%.

Ok, eine Frage hätte ich noch an Fabian: Wie kommst Du bei 2.69g Antimaterie auf eine Energie von 2.905*10^10 J?

Also mein TR spuckt für W = mc² für 2.69 * 10^-3 kg den Wert 2,421*10^14 J aus. Das wäre klassisch gesehen 1583,921807 m/s; relativistisch gesehen kommt ebenfalls der gleiche Wert (bis zu dieser Nachkommastelle) heraus. (Hmmm, irgendwie verstehe ich dann die 0,03% Abweichung bei der *niedrigeren* Geschwindigkeit nicht... vielleicht Rundungsfehler im TR)

Egal, wirklich schnell ist das nicht, mit drei Liter Antimaterie kommt die Enterprise also nicht weit. :)

Viele Grüße,
Christian

[Klaus Mock]

Hallo,

Egal, wirklich schnell ist das nicht, mit drei Liter Antimaterie kommt die Enterprise also nicht weit. :)

Aber wird die Energie nicht dafür verwendet, eine Warp-Blase zu erzeugen, die dann den Raum um das Schiff so krümmt, dass auch Geschwindigkeiten jenseits der Lichtgeschwindigkeit möglich sind? Wieviel Energie ist eigentlich dazu nötig? Für diese Frage werden wir aber doch eher diesen Cochran oder wie der heisst, bemühen müssen;-)

Grüße
  Klaus

[Fabian Transchel]

Hallo Klaus,

Egal, wirklich schnell ist das nicht, mit drei Liter Antimaterie kommt die Enterprise also nicht weit. :)

Aber wird die Energie nicht dafür verwendet, eine Warp-Blase zu erzeugen, die dann den Raum um das Schiff so krümmt, dass auch Geschwindigkeiten jenseits der Lichtgeschwindigkeit möglich sind? Wieviel Energie ist eigentlich dazu nötig? Für diese Frage werden wir aber doch eher diesen Cochran oder wie der heisst, bemühen müssen;-)

Tja, wenn du das jetzt erklärst, und es dann auch noch funktioniert, dann würde ich sagen hast du den Nobelpreis sicher ;-)

Für diesen Vorgang ist nämlich nach Einstein unendlich viel Energie erforderlich.

Grüße aus Barsinghausen,
Fabian

[Fabian Transchel]

Hallo Christian,

Daher ist 1/2mv² durchaus anwendbar,

Fabian hatte insofern von Anfang an Recht, dass 1/2mv² nicht anwendbar ist. Allerdings ist mir sein Rechenweg immer noch unklar.

Ich habe beschlossen, dazu einen kleinen humnoristischen Artikel auf meiner Page zu veröffentlichen. Das wird allerdings einige Zeit dauern, da ich 1. mal das, was du und die anderen hier nun geleistet haben aufarbeiten muss und 2. das ganze nochmal akribisch durchprüfe, die Gleichungen sind schließlich nicht ganz einfach. Ich denke aber, dass diese zweite Arbeit von dir dem Ganzen schon ziemlich nahe kommen dürfte, werde ausserdem versuchen, jegliche Rundungsfehler da rauszurechnen.

In meinem Physikbuch steht nun folgendes:

Ein ruhendes Objekt hat die Ruheenergie W0 = m0 * c²

Ein sich bewegendes Objekt hat die Gesamtenergie W = m * c² mit m = m0/sqrt(1-v²/c²).

Folglich muss die Bewegungsenergie die Differenz beider Energien sein.

Um jetzt die kinetische Energie der Enterprise herauszubekommen, müssen wir zuerst die Ruheenergie berechnen:

W0 = m0 * c² = 193*10^6 kg * (3*10^8 m/s)² = 1,737*10^25 J

Daran habe ich beispielsweise nicht gedacht.

Nun addieren wir die kinetische Energie von 2,905 * 10^10 J, die Fabian berechnet hat. Die Gesamtenergie der sich bewegenden Enterprise entspricht also 1,737*10^25 J + 2,905 * 10^10 J. Dieser Term ist äußerst "doof". Jeder Taschenrechner rundet nämlich vorher.

Nun gilt:
[...]
Der Taschenrechner spuckt mir da als Ergebnis (algebraisch gerechnet und nur das Endergebnis approximiert) 17,35636838 m/s aus.

Wenn ich das klassich rechne mit Wkin = 1/2 m0v², dann komme ich auf folgendes Ergebnis: 17,35039681 m/s. Also immerhin ein Fehler von ca. 0,03%.

Ok, eine Frage hätte ich noch an Fabian: Wie kommst Du bei 2.69g Antimaterie auf eine Energie von 2.905*10^10 J?

Da wir hier von einer ruhenden Masse von 3 Litern Antimaterie ausgehen ist m.E. E = mc² verwendbar. Eingesetzt erhalten wir also E = 2,69g * 10^-3 kg * (3*10^8 m/s)². Das ist allerdings, beim Nachprüfen jetzt bemerkt 2,421 * 10^14 J (hatte die Lichtgeschwindigkeit von km/s in m/s falsch umgewandelt... *schäm*)

Du siehst also, dass ich da noch viel aufzuarbeiten habe *g*

Also mein TR spuckt für W = mc² für 2.69 * 10^-3 kg den Wert 2,421*10^14 J aus. Das wäre klassisch gesehen 1583,921807 m/s; relativistisch gesehen kommt ebenfalls der gleiche Wert (bis zu dieser Nachkommastelle) heraus. (Hmmm, irgendwie verstehe ich dann die 0,03% Abweichung bei der *niedrigeren* Geschwindigkeit nicht... vielleicht Rundungsfehler im TR)

Egal, wirklich schnell ist das nicht, mit drei Liter Antimaterie kommt die Enterprise also nicht weit. :)

Nein, das definitiv nicht. :)

Grüße aus Barsinghausen,
Fabian

[Christian Seiler]

Hallo Fabian,

Mal sehen. Bei Direktumwandlung von Materie in Energie gilt E = mc². Für drei Liter Antimaterie (wir gehen der Einfachheit halber mal von Anti-Wasserstoff aus) erhalten wir eine Antimaterie-Masse von 2,69 g (für eine Normaldichte von 0,0899 kg/m³ für Wasserstoff). Die daraus zu gewinnene Energie beträgt also 2,905 * 10^10 Joule.

Um die 2,69g Antimaterie zu vernichten, brauchst Du jedoch auch genauso viel Materie, um diese zu vernichten. Im Endeffekt hast Du also das vierfache an Energie. :)

daher erhalten wir mit E = mc² (diesmal nach c auflösen)

Hö? c ist eine Naturkonstante, die hat sich zumindest in den letzten 50 Jahren nicht geändert. Und da kommen so läppische 193e6 kg an (nix im Vergleich zu einem Stern oder so) und Du willst mir erzählen, dass man beim Beschleunigen ebendieser diese sich einfach ändert und dann auch noch die Geschwindigkeit darstellt, die das Objekt nach der Beschleunigung hat? Wie kommst Du auf den Trichter?

Viele Grüße,
Christian

[Fabian Transchel]

Hallo Christian,

Mal sehen. Bei Direktumwandlung von Materie in Energie gilt E = mc². Für drei Liter Antimaterie (wir gehen der Einfachheit halber mal von Anti-Wasserstoff aus) erhalten wir eine Antimaterie-Masse von 2,69 g (für eine Normaldichte von 0,0899 kg/m³ für Wasserstoff). Die daraus zu gewinnene Energie beträgt also 2,905 * 10^10 Joule.

Um die 2,69g Antimaterie zu vernichten, brauchst Du jedoch auch genauso viel Materie, um diese zu vernichten. Im Endeffekt hast Du also das vierfache an Energie. :)

Das stimmt allerdings, hab ich völlig verplant. :)

daher erhalten wir mit E = mc² (diesmal nach c auflösen)

Hö? c ist eine Naturkonstante, die hat sich zumindest in den letzten 50 Jahren nicht geändert. Und da kommen so läppische 193e6 kg an (nix im Vergleich zu einem Stern oder so) und Du willst mir erzählen, dass man beim Beschleunigen ebendieser diese sich einfach ändert und dann auch noch die Geschwindigkeit darstellt, die das Objekt nach der Beschleunigung hat? Wie kommst Du auf den Trichter?

Hab ich so gelesen.[1] (Oder falsch verstanden.) Nein, natürlich ist c unveränderlich bei 300.000 km/s abzüglich ein paar Zerquetschter, aber in E = mc² heißt es m.E. nur c (statt der gebräuchlichen Variablenbezeichnung v für Geschwindigkeit) um zu verdeutlichen, dass c der unerreichbare Granzwert für Geschwindigkeiten ist.

Ich werde nachher, wenn ich vom Badminton-Training wieder da bin, nochmal gründlich nachrechnen, aber prinzipiell denke ich, wenn du Recht hättest, dann müsste ich für c doch (wieder) die Lichtgeschwindigkeit erhalten, und das was ich hier jetzt herausbekomme ist nicht annähernd in der Richtung.

[1] Nicht im Sinne von "meine ich mal gelesen zu haben", sondern von "_kürzlich_ so in Erfahrung gebracht" :)

Grüße aus Barsinghausen,
Fabian