welche programmiersprache für Programme benutzen?
-
toilettenpapier schrieb:
In wo?
Es heißt worin.
Fragewörter sterben leider auch aus.Ich versuche mal eine halbwegs objektive Zusammenfassung zu geben:
C ist eine maschinennahe und sehr einfache Sprache mit sehr einfacher Syntax. Schon nach einer Woche kannst du auf praktisch beliebigen C-Code sehen und weißt was dort passiert. Nicht was es bedeutet, aber was es tut. C überlässt es dir deinen Code zu strukturieren und du musst dich generell um alles selbst kümmern, sehr effizient aber umständlich.
C++ ist eine Erweiterung von C. C++ hilft dir deinen Code zu organisieren. Du kannst immernoch C-Code schreiben, aber zusätzlich unterstützt es Klassen und Vererbung. In C musst du Vererbung selbst organisieren, in C++ gibt es vorgefertigte Ausdrücke um es zu machen. Gleichzeitig geht aber damit auch Übersicht verloren. "i++;" ist ein Ausdruck der in C bedeutet, dass i um eins hochgezählt wird. In C++ er auch k um 1 verringern. Oder ein Fenster aufmachen. Oder sonst irgendwas tun. Und um das herauszufinden musst du eventuell viele Klassen und Elternklassen durchsuchen. C++ funktioniert mehr nach dem Prinzip "du musst es nicht verstehen, es reicht wenn du es benutzen kannst".
Java ist "objektorientiert". Das heißt im Prinzip "alles ist ein Objekt" und du musst für alles Klassen und Methoden schreiben. Damit zwingt es dich deinen Code zu organisieren. Während man in C und C++ allen möglichen Blödsinn schreiben kann, gibt es in Java weniger Möglichkeiten dazu. Java kümmert sich um deinen Speicher, weniger effizient als du es könntest, aber schon nett. Ich mag Java allerdings nicht, denn die Vereinfachung die man sich durch Performanceverluste erkauft hat, bedeutet nicht weniger Entwicklungsaufwand, sondern mehr.
Python ist so nah an der menschlichen Sprache, dass es kinderleicht ist darin Programme zu schreiben. Du kannst dich voll auf das eigentliche Programm konzentrieren, organisatorischer Krimskrams wie Variablentypen macht Python für dich. In den vorherigen Sprachen hatten zum Beispiel Zahlen (ints) einen gewissen Speicher und damit einen Wertebereich. Wenn dieser überläuft kommt Blödsinn raus. In Python nicht, der Speicher den eine Variable beansprucht wird automatisch angepasst. Diese automatische Anpassung sorgt dafür dass die Operationen immer funktionieren, es macht sie aber auch langsam.
Du solltest dich nicht für eine Sprache entscheiden, sondern dir überlegen worauf du Wert legst. Ausführungsgeschwindigkeit? Entwicklungsgeschwindigkeit? Organisierst du deinen Code selbst oder soll das die Sprache machen? Bist du bereit CPU-Zyklen zu opfern damit du dich nicht um Speicher kümmern musst?
Sollten sich deine Prioritäten irgendwann ändern ist es relativ leicht auf eine andere Srache zu wechseln.
-
nwp2 schrieb:
C++ ist eine Erweiterung von C. C++ hilft dir deinen Code zu organisieren. Du kannst immernoch C-Code schreiben, aber zusätzlich unterstützt es Klassen und Vererbung. In C musst du Vererbung selbst organisieren, in C++ gibt es vorgefertigte Ausdrücke um es zu machen. Gleichzeitig geht aber damit auch Übersicht verloren. "i++;" ist ein Ausdruck der in C bedeutet, dass i um eins hochgezählt wird. In C++ er auch k um 1 verringern. Oder ein Fenster aufmachen. Oder sonst irgendwas tun. Und um das herauszufinden musst du eventuell viele Klassen und Elternklassen durchsuchen. C++ funktioniert mehr nach dem Prinzip "du musst es nicht verstehen, es reicht wenn du es benutzen kannst".
Das tut ja schon beim lesen weh, Autsch...
-
Janjan schrieb:
Das tut ja schon beim lesen weh, Autsch...
Absolut nicht. nwp2 hat nichts falsches geschrieben.
-
Es wurden allgemeine Behauptungen aufgestellt und mit eher Kleinigkeiten untermauert. Von objektiv kann da auch nicht die Rede sein. Natuerlich kann "i++" viel bedeuten, aber: Wenn ich "Buch" sage, dann kann das auch was anderes fuer mich bedeuten (gerade die Bedeutung, die ich ihm gebe). Aber es gibt einen allgemeinen Konsens, was "Buch" in Deutschland bedeutet. Genauso gibt es einen allgemeinen Konsens, was "i++" bedeutet. Es wird kein Fenster aufmachen. Und ich werde auch nicht in der Klassenhierarchie danach suchen. Zu Python: Ich fand es ganz und gar nicht nah an der menschlichen Sprache.
-
nwp2 schrieb:
Bist du bereit CPU-Zyklen zu opfern damit du dich nicht um Speicher kümmern musst?
kommt von jemandem der seinen code mit malloc spickt
nwp2 schrieb:
Schon nach einer Woche kannst du auf praktisch beliebigen C-Code sehen und weißt was dort passiert. Nicht was es bedeutet, aber was es tut.
frag mich was ich hier die ganze zeit im forum mach und mir bei 500 seiten C99 standard immer noch ein paar sachen "unklar" sind.
und um nicht total zum troll zu mutieren kann ich nur den vorschlag machen, ein möglichst schönes framework mit gui-editor zu nehmen da sparst dir ne ganze menge getippe. gui code von hand zu schreiben ist einfach nicht lustig...
lg lolo
-
veritySeeker schrieb:
Janjan schrieb:
Das tut ja schon beim lesen weh, Autsch...
Absolut nicht. nwp2 hat nichts falsches geschrieben.
Bereits der erste Satz zu C++ ist falsch. C++ ist keine Erweiterung von C, sondern eine eigenständige Sprache. Wenn es eine Erweiterung wäre, müsste es ja zum Beispiel rückwärtskompatibel zu C99 sein, ist es aber nicht!
Es ist unteranderem aus C heraus entstanden, dass wäre richtig. Heutzutage ist es aber eine vollständig eigenständige Sprache.Und auch die restliche Argumentation ist ziemlicher Murks. Es wird kein vernünftiger Mensch darauf kommen, dass i++ eine Reduzierung der Variable auslöst. Man kann es zwar machen, aber es tut keiner, weil es einfach nur verwirrend und unlogisch wäre. Also wozu sowas unsinnges aufführen?
Aber naja ... bevor es noch wie in den anderen Threads endet, höre ich besser auf.
nwp2 schrieb:
Du solltest dich nicht für eine Sprache entscheiden, sondern dir überlegen worauf du Wert legst. Ausführungsgeschwindigkeit? Entwicklungsgeschwindigkeit? Organisierst du deinen Code selbst oder soll das die Sprache machen? Bist du bereit CPU-Zyklen zu opfern damit du dich nicht um Speicher kümmern musst?
Sollten sich deine Prioritäten irgendwann ändern ist es relativ leicht auf eine andere Srache zu wechseln.Der erste Satz ist absolut richtig. Aber danach wird es recht sinnlos. Wie willst du die Auführungsgeschwindigkeit bewerten? Wie willst du die Entwicklungsgeschwindigkeit bewerten? Nach welchen Kriterien? Sowas ist vielfach nur sehr schwer definierbar.
Man sollte vielmehr bewerten, in welche Richtung man eigentlich möchte, was einem interessiert. Will man im Low-Level Bereich Programmieren, zum Beispiel Treiberprogrammierung, Betriebsysteme, usw.? Oder vielleicht lieber Business-Software? Vielleicht Monitoringwerkzeuge für einen bestimmten Bereich? Usw. usf.
Auch in diesen Fällen gibt es dann immer noch mehrere Sprachen zur Auswahl, aber man kann es zumindest ein wenig eingrenzen. Zum Beispiel wirst du für die Treiberprogrammierung eher C# nicht verwenden.
Wie man dann aus den noch übrigbleibenden Sprachen aussucht, läuft dann am Ende oft einfach nur auf den Geschmack hinaus.Grüssli
-
Zu C++: Klassen und Vererbung sind zwar das, was man an C++ vielleicht am meisten spürt, aber Prozentual ist das halt trotzdem nicht so viel. Außerdem bringen diese kleinen "Erweiterungen" sehr viel für das Programmieren von Bibliotheken, vergleiche halt mal WinAPI mit einem modernen GUI-Toolkit (auch wenn so was wie wxWidgets auch nicht modernstens programmiert ist).
@Dravere: Ich denke schon, dass man die Ausführungsgeschwindigkeit bewerten kann, deshalb nimmt man ja kein C# für Treiber usw. Bei GUI-Programmen ist der Umfang hingegen relativ groß, von C bis zu den ganzen Skriptsprachen.
-
Wer sich gern an C++ vs. alle anderen beteiligen will, der hat hier im Kommentarbereich wieder gute Chancen: http://www.heise.de/newsticker/meldung/iX-Workshops-mit-C-Guru-Scott-Meyers-979060.html
-
Dravere schrieb:
C++ ist keine Erweiterung von C, sondern eine eigenständige Sprache. Wenn es eine Erweiterung wäre, müsste es ja zum Beispiel rückwärtskompatibel zu C99 sein, ist es aber nicht!
Eine ganz schlechte Begründung.
C++ war bei seiner Geburt ein Spin-Off von C. Daß C inzwischen eigene Wege ging und C++ hinter sich lies (durch C99), heißt nicht, daß man C++ nicht auch als Erweiterung von C ansehen kann. Stroustrup selbst sagte einst während eines Interviews: "C++ is a better C".
-
veritySeeker schrieb:
Daß C inzwischen eigene Wege ging und C++ hinter sich ließ (durch C99)...
Und jetzt versucht C++0x, wieder C99-Konform zu werden.
-
Stroustrup selbst sagte einst während eines Interviews: "C++ is a better C".
Ja und? Ueber Java sagt man, es sei ein besseres C++. Dennoch ist Java keine Erweiterung von C++. Alles Bullshit.
-
Bestes Beispiel das C++ keine Erweiterung von C ist:
int *a = malloc(sizeof(int));In C legal, in C++ nicht.
-
wxSkip schrieb:
Zu C++: Klassen und Vererbung sind zwar das, was man an C++ vielleicht am meisten spürt, aber Prozentual ist das halt trotzdem nicht so viel. Außerdem bringen diese kleinen "Erweiterungen" sehr viel für das Programmieren von Bibliotheken, vergleiche halt mal WinAPI mit einem modernen GUI-Toolkit (auch wenn so was wie wxWidgets auch nicht modernstens programmiert ist).
Da muss ich massiv widersprechen. Ich bastle an einem größeren Projekt mit der WinAPI, es klappt ziemlich gut. Manchmal muss ich etwas suchen, aber am Ende habe ich immer die entsprechende Funktion gefunden.
Dann wollte ich es nach Linux portieren. Alles ist gut modularisiert, man muss nur eine handvoll Funktionen finden die ein Fenster aufmachen und Text malen. Ich habe es mit QT versucht und habe es aufgegeben, wegen C++. Man findet nichts. Mein Versuch mit GTK ist daran gescheitert, dass es keine Dokumentation gibt, nur für die C++ Bindings. Ich suche gezielt nach C-Bibliotheken weil die so einfach zu benutzen sind und meide C++ Bibliotheken weil man da überhaupt nicht durchsehen kann.
-
nwp2 schrieb:
Ich habe es mit QT versucht und habe es aufgegeben, wegen C++.
Wenn du Qt nicht benutzen kannst, dann solltest du das Programmieren vielleicht ganz sein lassen. Qt ist mit Abstand die am einfachsten zu benutzende Bibliothek mit der besten Dokumentation.
Tausend mal besser als die ganzen C Bibliotheken mit kryptischen Namen, Void-Zeigern und endlos vielen unnötigen Strukturen.
-
Qt und WinAPI sind zwei verschieden Konzepte (insbesondere der signal-slot-Mechanismus), die sich auch auf das Programmdesign auswirken. Eine reine Portierung ist damit ausgeschlossen.
-
Warum mir alle immer die Programmiererei ausreden wollen, ich muss wirklich schrecklich sein. Aber im ernst, ich habe meine GUI-Funktionen komplett von der Programmlogik abgekapselt. Es gibt nur Funktionen wie "mache ein Fenster auf", "male Text an diese Stelle" und so weiter. Ganz primitive Funktionen die jede GUI-Bibliothek hat. Und bei QT findet ich sie einfach nicht, denn ich komme mit den ganzen Window, Widget, Cairo, Device und wie-sie-alle-hießen Klassen nicht klar. Es gibt auch keine Dokumentation, es gibt nur Doxygen-generierte Header im HTML-Format. Außerdem gibt es bestimmt 5 verschiedene Klassen für Schriftarten und Devicecontexte die alle miteinander inkompatibel sind. Das beste was man machen kann ist sich von Tutorial zu Tutorial zu hangeln, aber wirklich vorwärts gekommen bin ich so nicht.
Ich hatte übrigens daran gedacht direkt XServer-Funktionen zu nehmen. Damit kann man nämlich ganz einfach Fenster aufmachen und Text malen. Allerdings müsste ich auch Menüs selber bauen, und darauf hatte ich keine Lust.Wenn ich irgendwann soweit bin dass es sich wirklich lohnt nach Linux zu porten werde ich mich damit nochmal beschäftigen.
Ich würde allerdings immer die WinAPI empfehlen und von QT abraten.
-
nwp2 schrieb:
Warum mir alle immer die Programmiererei ausreden wollen, ich muss wirklich schrecklich sein. Aber im ernst, ich habe meine GUI-Funktionen komplett von der Programmlogik abgekapselt. Es gibt nur Funktionen wie "mache ein Fenster auf", "male Text an diese Stelle" und so weiter. Ganz primitive Funktionen die jede GUI-Bibliothek hat. Und bei QT findet ich sie einfach nicht, denn ich komme mit den ganzen Window, Widget, Cairo, Device und wie-sie-alle-hießen Klassen nicht klar.
Warum sagen alle anderen, Qt sei Klasse?
Es gibt auch keine Dokumentation, es gibt nur Doxygen-generierte Header im HTML-Format.
Mega Bullshit: http://doc.trolltech.com/4.6/index.html . Da gibt es Tutorials, massenhaft Hintergrundwissen, alles was das Herz begehrt.
aber wirklich vorwärts gekommen bin ich so nicht
Dann hast du was falsch gemacht.
"male Text an diese Stelle"
GUIs abstrahieren vom Rendering. Falls du Rendering willst anstatt 'ne GUI, dann solltest du keine GUI nehmen. Es gibt jedoch Moeglichkeiten: z.B. Label erzeugen, Text setzen, Label auf Position setzen.
Ich würde allerdings immer die WinAPI empfehlen und von QT abraten.
Du hast nichts gelernt.
-
nwp2 schrieb:
ich habe meine GUI-Funktionen komplett von der Programmlogik abgekapselt. Es gibt nur Funktionen wie "mache ein Fenster auf", "male Text an diese Stelle" und so weiter. Ganz primitive Funktionen die jede GUI-Bibliothek hat.
Ich zweifle ernstlich, ob du dich schonmal mit GUI-Programmierung intensiv auseinander gesetzt hast. Man malt sich seine Oberfläche doch nicht selber, dafür gibt es z.B. unter Windows die STATIC-Fensterklasse oder irgendeine andere angepasstere. Was machst du, wenn du einen Button haben willst? Malst du da ein weißes Rechteck mit schwarzem Rand?
nwp2 schrieb:
Es gibt auch keine Dokumentation, es gibt nur Doxygen-generierte Header im HTML-Format.
Bitte was? Qt ist m.E. eine der bestdokumentierten C++-Bibliotheken überhaupt. Zur Dokumentation von Qt 4.7 gehts hier.
nwp2 schrieb:
Außerdem gibt es bestimmt 5 verschiedene Klassen für Schriftarten und Devicecontexte die alle miteinander inkompatibel sind.
Oha. Für Schriftarten kenne ich QFont, für Device-Kontexte... äh, wozu brauch man Device-Kontexte? Durch die Abstraktion muss man sich doch mit sowas dankenswerterweise nicht mehr rumschlagen.
nwp2 schrieb:
Das beste was man machen kann ist sich von Tutorial zu Tutorial zu hangeln, aber wirklich vorwärts gekommen bin ich so nicht.
Die Tuts sollte man sich bei jeder Bibliothek mal anschauen, aber gerade bei Qt sind die m.E. sehr verständlich.
nwp2 schrieb:
Ich würde allerdings immer die WinAPI empfehlen und von QT abraten.
Das ist natürlich immer eine Sache des Geschmacks, aber für mich ist WinAPI viel zu low-level und zu unportabel.
-
-
Ich nehme das über die Doku von QT zurück. Hab QT mit GTK verwechselt. QT hatte ich aufgegeben wegen c++. Das war wohl etwas vorschnell.
"male Text an diese Stelle"
GUIs abstrahieren vom Rendering. Falls du Rendering willst anstatt 'ne GUI, dann solltest du keine GUI nehmen. Es gibt jedoch Moeglichkeiten: z.B. Label erzeugen, Text setzen, Label auf Position setzen.
Meine Programmlogik erfordert aber nunmal, dass ich ein Fenster mit Menü habe und dort Text reinmalen kann. Meine Idee war, dass ich einfach die Textmalfunktionen ersetze und schon läufts unter Linux.
Dass es die Funktionen, die ich mir überlegt habe, in QT nicht gibt, zeigt mir eigentlich nur, dass QT ungeeignet dafür ist.Ich habe auch etwas in der QT-Doku geblättert und weiß wieder warum ich QT doof fand. Ich will zum Beispiel eine Linie malen. Ich finde die QGraphicsLineItem Klasse. Dort schickt man mich zu QGraphicsScene. Um die zu erzeugen brauche ich ein QObject. Und nein, ein Fenster ist kein QObject. Also muss ich irgendwie herausfinden, wie ich aus dem Fenster ein QObject mache um eine QGraphicsScene zu erzeugen die ein QGraphicsLineItem hat welches mit eine Linie mal. Wenn es so überhaupt möglich ist.
Da lob ich mir die WinAPI, DrawLine und fertig.
Ich würde allerdings immer die WinAPI empfehlen und von QT abraten.
Du hast nichts gelernt.
Doch, ich habe gelernt, dass ich als Vollnoob super mit der WinAPI arbeiten kann und trotz reichlich mehr Erfahrung aus QT nicht schlau werde.
Ich kann mir gut vorstellen, dass QT super funktioniert, wenn man sein Programm um QT herum baut. Wenn man sich allerdings Funktionen überlegt und die mit QT implementieren will funktionierts nicht. Da ich wegen Portabilität auf letzteres angewiesen bin (Nein, ich will keine 13MB von QT für Windows mitschleppen), bleibt mir nichts weiter übrig, als eine andere Bibliothek zu suchen.GUIs abstrahieren vom Rendering.
Das erklärt warum es nicht funktioniert wie ich das wollte. Aber es ändert nichts an der Tatsache dass es nicht funktioniert.
