C++ vor Java lernen?

[Nite]

Nabend.
Ich bin ein großer Fan von Java und mein erstes richtiges Programmierbuch war ein Javabuch. Ich beherrsche bereits einige Scriptsprachen wie CGI/Perl, PHP, ShellSkript kann relativ gut mit Batch-Dateien umgehen.
Nun wollte ich aber gerne richtige Programme für einen Endanwender schreiben und auch für mich um Dinge auszubessern, die mir an anderen Programmen nicht gefallen.
Mein zweites Buch war ein C++ Buch (beides waren nur Einsteigerbücher) und dort stand drin, man könne besser erst C++ lernen, dann Java. Ich bin mir da aber nicht ganz so sicher...

Was also machen? Stimmt das so?

Danke

 

[Campino]

Erst Java, dann C++, weil Java wesentlich einfacher zu handhaben und zu erlernen ist.

 

[L-ectron-X]

Du hast es doch gemacht und kannst es am besten beurteilen.

 

[Verjigorm]

hatte erst 2 Jahre C++ und dann auf Java umgestiegen und es war das beste was ich gemacht habe!

 

[Nite]

Du hast es doch gemacht und kannst es am besten beurteilen.

Nunja... Ich bin seit dem ich das gelesen hatte, dass es besser sei erst C++ zu lernen doch nachdenklich. Habe auch schon mehrfache Anläufe gemacht mir C++ gewaltsam "einzutrichtern", aber zwischendurch habe ich immer mal wieder aufgehört - also zu lesen. Habe mir 2 Bücher bestellt und diese vergammeln mehr oder weniger...
Okay, das ist nun keine richtige Erklärung, aber ich habe es mehr oder weniger immer wieder versucht um später Java lernen zu können.
Hört sich zwar dumm an, aber so ist's nunmal. :lol:

@Topic: Ich danke euch. Ich werde dann wohl mit Java anfangen und C++ folgen lassen.
Ich habe nur ein Anfängerbuch gelesen und bräuchte wohl ein Buch (am besten eBook) über folgende Themen (so steht's im Einsteigerbuch, was ich gelesen habe):

• Vererbung von Klassen
• Überschreibung von Methoden und Polymorphismus
• Implementierung von Schnittstellen (Interfaces)
• Exceptions
• Threads
• Erstellung von GUI-Anwendungen mit AWT und Swing
• Programmierung von Applets

Eine empfehlung steht auch drin: »Ich lerne jetzt Java« von Dirk Louis und Peter Müller. Aber kennt jemand ein gutes eBook, dass diese Themen befasst, oder vielleicht ein Buch?

Vielen Dank

 

[Nite]

Hmm... Registrationen sind nervig, aber geben einem den Edit-Knopf.... :?
Ich hatte noch eine Frage: Ich habe 2 Systeme, Linux und Windows. Ich bin mal auf dem einen, mal auf dem andern. Sollte ich mich bei dem Lernen auf eines festlegen, oder spielt das keine Rolle? Sollte nicht, oder? Java hat ja seinen eigenen Code und interpretiert ihn durch JRE.

Danke

 

[Jango]

http://www.galileocomputing.de/openbook/javainsel6/

 

[Marcel_Handball]

folgendes wird immer wieder gerne empfohlen: www.galileocomputing.de/openbook/javainsel6/

 

[Jango]

Hmm... Registrationen sind nervig, aber geben einem den Edit-Knopf.... :?
Ich hatte noch eine Frage: Ich habe 2 Systeme, Linux und Windows. Ich bin mal auf dem einen, mal auf dem andern. Sollte ich mich bei dem Lernen auf eines festlegen, oder spielt das keine Rolle? Sollte nicht, oder? Java hat ja seinen eigenen Code und interpretiert ihn durch JRE.

Danke

Bei Java ist das egal, aber wenn du dich entscheidest, CSharp zu lernen, ist Windows die bessere Lösung.

Edtit: @ Marcel Handball: Doppelt hält besser, was?

 

[Nite]

Vielen Dank euch beiden.

C# ist doch sowieso Windows-Only? Ist doch eine Enwicklung von MS, soweit ich weiß - hab mich da nicht so wirklich aus einander gesetzt.^^

 

[Jango]

Vielen Dank euch beiden.

C# ist doch sowieso Windows-Only?

Nein, aber das gehört hier nicht her... :wink:

 

[L-ectron-X]

Mit Mono gibts eine mehr oder weniger gute Portierung des .NET-Frameworks für Linux.

 

[sparrow]

Bei dem Thread muss ich mich mal wieder fragen wo genau Jango hier eigentlich was c# gelesen hat?

@Nite
"Richtige" Anwenderprogramme kannst du durchaus auch mit Java schreiben.
Ansonsten gab es mal einen schönen Spruch in einem C++ Buch das mir mal unter gekommen ist: "Wenn Sie Erfahrung mit Java sammeln konnten haben Sie Glück, denn unter Java kann man nur so programmieren wie man es unter C++ tun sollte."

 

[L-ectron-X]

Der Spruch gefällt mir. Den würde ich mir glatt in die Signatur legen.

 

[Leroy42]

C# ist doch sowieso Windows-Only? Ist doch eine Enwicklung von MS, soweit ich weiß

Es ist eine, mehr oder weniger, schlechte Raubkopie von Java.

 

[thE_29]

<ot> Sun hat sich da selbst ins Knie geschossen, da sie ja gesagt haben MS darf keine Java VM machen (gab ja bis java 1.1 eine MS Portierung).
Tjo, daraufhin haben sie halt was eigenes gemacht :bae:</ot>

Also ich habe 5 Jahre C/C++ gelernt und bin dann auf Java umgestiegen. Manchmal vermisse ich ein paar Features von C++ halt, aber sonst ist Java nicht schlecht! Vorallem das Exceptionhandling ist gut.. (Speicher würde ich mich aber manchmal selbst kümmern wollen, Operatoren überladen, etc..).

Naja, was solls zZ tuts auch Java (obwohl ich gerade wieder am C++ proggen bin :bae

 

[AlArenal]

@the_29:

Das ist Verdrehung von Tatsachen. Es war vielmehr so, dass MS Lizenznehmer war und in die eigene VM inkompatible Erweiterungen eingebaut hat (das macht man in Redmond gerne, siehe die Browser-Kriege) und das lief Sun zuwider, MS wollte davon aber nicht ablassen. Also gabs Zoff und das Ende ist bekannt.

Mit der IBM Version gabs dererlei Probleme nicht. Die Jungs benehmen sich nämlich anständig

 

[thE_29]

Jo, das MS da immer selber rumbasteln will war klar
Haben ja dieses krank J++ ja auch gemacht..

Naja, was solls, da Java ja e open source wird, wirds solche Verdrehungen bald genug geben!

Und IBM baut ja nur JVM auf Systemen die sun net machen will (ok, es gibt zwar auch für Windows welche, aber meistens macht IBM halt für ihre perversen Systeme diese JVM).

 

[AlArenal]

Open Source muss nicht zu "Verdrehungen" führen. Dafür gibt es schließlich das Mittel der Zertifizierung (durch die die MS VM immer durchgerasselt ist).

 

[Wildcard]

<ot> Sun hat sich da selbst ins Knie geschossen, da sie ja gesagt haben MS darf keine Java VM machen (gab ja bis java 1.1 eine MS Portierung).
Tjo, daraufhin haben sie halt was eigenes gemacht :bae:</ot>

Und bei dem astronomischen Betrag den M$ am Ende an SUN zahlen musste hat sich wohl eher M$ ins virtuelle Knie geschossen :wink:

 

[thE_29]

Naja, das Geld braucht SUN sowieso für ihre Streiterein rund um Linux und SCO

 

[Wildcard]

Naja, das Geld braucht SUN sowieso für ihre Streiterein rund um Linux und SCO

Hab ich was verpasst? Da gehts doch primär um IBM. Ich hab nur mitbekommen das SCO der Meinung war das SUN OpenSolaris nicht unter GPL stellen kann.

 

[byte]

Naja, was solls, da Java ja e open source wird, wirds solche Verdrehungen bald genug geben!

Alles, was nicht kompatibel ist, darf sich zumindest nicht Java nennen. Vielleicht gehts dann bald so wie in den Viagra Mails, was verdrehen von Konsonanten/ Vokalen angeht. :roll:

 

[thE_29]

Toll.. Wozu soll es dann OpenSource werden?!

Solange es das kann was die originale kann isses ja kompatibel oder? Dh, es können nur neue Features eingebaut werden!

Was hat den die MS JVM gemacht? Gingen da nicht mal mehr Standard Java sachen?

@Wildcard: http://www.heise.de/newsticker/result.xhtml?url=/newsticker/meldung/83944

Da gehts zwischen SCO Group vs Linux (vs IBM) und SCO == Sun ; http://www.heise.de/ct/hintergrund/meldung/44492

 

[function]

Naja ich glaube die diskusion schweift etwas vom eigentlichen thema ab.
Aber meine meinung zum Thema ist, dass es erst einmal egal ist womit man anfängt hauptsache man versteht schonmal das grundprinzip von Programmiersprachen. Im normalfall fängt man ja eh prozedural an und startet in Java nicht mit komplexen OOP an.
Allerdings sollte man in betracht ziehen, dass man sich bei c/c++ schnell dirty tricks aneignet, mit denen man in java übelst auf die nase fällt.
Also meines er achtens nach sollte man sich in beide einmal etwas einlesen/einarbeiten und dann schauen, was einem besser gefällt. Es gibt ja auch die möglichkeit beides parallel zu erlernen.

 

[bronks]

... Was hat den die MS JVM gemacht? Gingen da nicht mal mehr Standard Java sachen? ...

Es war nicht nur die VM, sondern es gab auch ein MS Java SDK. MS hat ein paar neue recht brauchbare Features dazugebastelt. U.A. waren ein paar windowsspezielle Sachen dabei, die auf anderen System nicht funktionieren konnten.

 

[Daniel_L]

Nun wollte ich aber gerne richtige Programme für einen Endanwender schreiben und auch für mich um Dinge auszubessern, die mir an anderen Programmen nicht gefallen.

Ich habe ziemlich lange C++ programmiert, steige nun auf Java um. Viele Sachen, gerade im Bereich der Objektorientierung, sind ja ähnlich (Vererbung, Überschreiben...). Ich hab noch nicht den genauen Überblick über Java, würde aber sagen, die größten Unterschiede sind vor allem:

- radikalere Ausrichtung auf OOP bei Java (und dadurch konsequentere Anwendung "richtigen" Programmierstils im Vergleich zu C++)

- Exceptions-Handling in Java (vermeidet Programmabstürze, indem die Fehler "abgefangen" werden)

- Keine Pointer und notwendige Speicherverwaltung in Java. Dies hat einerseits Vorteile, weil der Garbage-Collector aufräumt und man nicht ausversehen unnötigen Speichermüll zurückbehält, wie es bei C++ schnell passieren kann. Pointer fand ich nicht schlecht bei C++, da bin ich noch gespannt, inwiefern ich dafür funktionale äquivalente Code Schnipsel in Java erstellen kann.


Die Grundlagen von Java und C++ lernen sich fast identisch leicht/schwer. Ich würde mich zuallererst fragen, für wen du Programme erstellen möchtest und auf welchen Betriebssystemen sie laufen sollen. Und direkte Anschlussfrage: Welche IDE?

Ich möchte bald auf Linux umsteigen, und da dürfen meine eigenen Programme natürlich nicht fehlen. Also kam für mich sowieso nur eine plattformunabhängige Sprache in Frage. Bleibt: Java, C# oder ggf. C++/Qt (sofern KDE bald auf Windows erscheint). Die .net-Portierungen auf Linux, Mac etc. sind mir etwas unsicher, da von MS nicht richtig unterstützt. Daher hab ich mich für Java entschieden.

Ein anderer Grund war eben, dass es für Java sehr gute kostenlose IDEs gibt (Netbeans - meiner Meinung nach besonders für Desktop-Anwendungen geeignet; Eclipse - wird von vielen favorisiert, meiner Meinung nach mittlerweile zu unrecht, weil Netbeans gut nachgelegt hat).

Wenn du nur für Windows programmieren möchtest, und Geld für Visual Studio hast, würde ich C++ oder vielleicht sogar C# empfehlen. Ansonsten würde ich an deiner Stelle zu Java wechseln. Vor allem sehr wichtig ist die Community, die a) für die Sprache und b) für die IDE zu finden ist. Für meinen alten C++Compiler/IDE gibt es leider gar nichts (mehr). Und ich wollte nicht in 5 Jahren noch Programme im Windows-95-Look erstellen, die vielleicht bereits auf Vista gar nicht mehr laufen. Daher musste ich sowieso die IDE wechseln. Und dann bot sich gleich ein Sprachwechsel an, denn die Einarbeitung in die IDE ist meiner Meinung nach noch zeitaufwändiger, Java lernt sich (fast) nebenbei, wenn man vorher C++ kannte.

 

[Daniel_L]

Noch ein Nachtrag: Das Markt&Technik-Buch, das du erwähnt hast, finde ich auch ganz gut. Preis/Leistungs-Verhältnis ist sehr gut.

Neben der Javainsel gibt es auch noch von Sun Java-Tutorials sowie Swing-Tutorials - und noch tausend weitere Seiten...

 

[Wildcard]

Ein anderer Grund war eben, dass es für Java sehr gute kostenlose IDEs gibt (Netbeans - meiner Meinung nach besonders für Desktop-Anwendungen geeignet; Eclipse - wird von vielen favorisiert, meiner Meinung nach mittlerweile zu unrecht, weil Netbeans gut nachgelegt hat).

Die Wahl für Eclipse ist nicht alleine in der IDE begründet. Wenn es so wäre hätte wohl Intelli J den größten Marktanteil.
Vielmehr geht es darum das praktisch jede größere IT Firma in der Eclipse Foundation vertreten ist und Eclipse damit zum absolut mächtigsten Entwicklertool geworden ist.
Der Gedanke der dahintersteht ist, dass man sämtliche Entwicklungstätigkeiten in einem Framework erschlagen kann, obwohl in einigen Bereichen spezialisierte Einzeltools eventuell etwas besser sind.

 

[Daniel_L]

Zumindest für Swing und Desktop-Anwendungen habe ich gehört, dass Netbeans brauchbarer sein soll. Das war auch mein erster Eindruck, als ich zuerst Eclipse (auf Empfehlung) und anschließend Netbeans grob angetestet habe. In einem Blogbeitrag von mir sind auch verschiedene Artikel verlinkt, die die Entwicklung Netbeans als positiv beschreiben und meinen, dass der Marktanteil von Eclipse und Netbeans sich mehr und mehr angleicht (sprich: Netbeans holt auf). Und zwei der Artikel sind von IBm respektive einem Eclipse-Anwender verfasst.

Aber, ich denke letztlich muss jeder selbst entscheiden, jegliche Argumentation für/gegen eine bestimmte IDE führt letztlich immer zum "leidigen" Thema A vs. B, Browserkrieg, Java vs. C#, Linux vs. Win, Netbeans vs. Eclipse etc. ;-)

Ich bin zumindest froh, eine Wahl zu haben.

 

[Wildcard]

Zumindest für Swing und Desktop-Anwendungen habe ich gehört, dass Netbeans brauchbarer sein soll.

Meiner Meinung nach sind GUI Builder grober Unfug, daher spielt klicki-bunti Mantisse bei meiner Wahl auch keine Rolle.

In einem Blogbeitrag von mir sind auch verschiedene Artikel verlinkt, die die Entwicklung Netbeans als positiv beschreiben und meinen, dass der Marktanteil von Eclipse und Netbeans sich mehr und mehr angleicht (sprich: Netbeans holt auf).

Netbeans ist gut, keine Frage.
Trotzdem steht SUN gegen den Rest der Welt, Eclipse bleibt im Enterprise Bereich der Platzhirsch.
Das liegt schon daran, dass alle Unternehmen die ihre Tools mittlerweile ausschließlich als Eclipse Plugins entwickeln (sowohl interne als auch öffentliche) auch erstmal bei dieser IDE bleiben werden.
Des Rennen bei den unabhängigen Programmierern wird das Framework mit den meisten Features machen.
Wenn die beste PHP IDE (von Zend), der beste BPEL/Webservice, die beste J2ME Umgebung (von Nokia) Eclipse Plugins sind (um nur ein paar zu nennen), dann ist für mich der Sieger im Rennen abzusehen.
Intelli J hat diesen Trend erkannt und bietet clevererweise die Möglichkeit Eclipse Plugins zu entwickeln.
Der derzeitige Marktanteil von über 50% (hier sind die ganzen Eclipse RCPs nichtmal eingerechnet) spricht auch Bände...

Ich bin zumindest froh, eine Wahl zu haben.

Dem schließe ich mich an.

 

[schalentier]

Intelli J hat diesen Trend erkannt und bietet clevererweise die Möglichkeit Eclipse Plugins zu entwickeln.

Und bald auch die Moeglichkeit, Eclipseprojekte direkt zu oeffnen und zu nutzen und damit problemlos an einem bestehenden Eclipseprojekt mit IDEA zu arbeiten. *freu*... Fehlt nur noch, dass man Eclipse Plugins in IDEA einbinden kann... oder ein IDEA-Eclipse Plugin...

 

[Wildcard]

oder ein IDEA-Eclipse Plugin...

Bin dafür :toll:

 

[Roar]

Fehlt nur noch, dass man Eclipse Plugins in IDEA einbinden kann...

sehr coole idee, mit swingwt/swtswing und viel zeit könnte das sogar klappen

 

[Daniel_L]

Meiner Meinung nach sind GUI Builder grober Unfug, daher spielt klicki-bunti Mantisse bei meiner Wahl auch keine Rolle.

Für mich war es der ausschlaggebende Grund für die Einarbeitung in Netbeans und damit auch Java. ;-) Aber ein Programm mit zahlreichen Fenstern, die alle mehrere Elemente enthalten, per "Hand" (also ohne GUI-Builder) zu erstellen, ist doch ziemlich mühselig, oder? Zumindest zeitraubend.

 

[Wildcard]

Aber ein Programm mit zahlreichen Fenstern, die alle mehrere Elemente enthalten, per "Hand" (also ohne GUI-Builder) zu erstellen, ist doch ziemlich mühselig, oder? Zumindest zeitraubend.

Nein, überhaupt nicht. Wenn man das System versteht geht es sehr flott von der Hand und man kann sich sicher sein das der Code sauber und flexibel ist.
Ich denke nicht das es in Java High-Quality Programme gibt die GUI-Builder verwenden.

 

[AlArenal]

Meiner Meinung nach sind GUI Builder grober Unfug, daher spielt klicki-bunti Mantisse bei meiner Wahl auch keine Rolle.

Meiner Meinung nach sind derartige Aussagen grober Unfug

 

[Daniel_L]

Ich denke nicht das es in Java High-Quality Programme gibt die GUI-Builder verwenden.

Dann muss ich das erste schreiben. ;-)

 

[Wildcard]

Meiner Meinung nach sind derartige Aussagen grober Unfug

Zum Glück hat jeder seine eigene

 

[Guest]

Ich denke über den Punkt GUI-Builder kann man sich immer streiten. Ich persönlich bevorzuge auch meine GUI selber zu erstellen, auch wenn das am Ende im Normal etwas mehr Aufwand mit sich bringt. Mir ist der Vorteil, dass der Code meinen Vorstellungen (und vor allem unseren Programmiervorgaben) entspricht wichtiger als das schnell Zusammenklicken. Mal abgesehen davon, dass ich wahrscheinlich länger bräuchte den erzeugten Code an unsere Programmierrichtiglinien anzupassen, als ich brauche das ganze gleich selber zu schreiben.

 

[AlArenal]

Meiner Meinung nach sind derartige Aussagen grober Unfug

Zum Glück hat jeder seine eigene

Zum Glück ändert die Meinung allein auch nicht die Realität, die die Meinung meint abzubilden.

 

[Wildcard]

Zum Glück ändert die Meinung allein auch nicht die Realität, die die Meinung meint abzubilden.

Grundsätzlich schließe ich mich der Aussage von Gast an.
Ist nicht so das ich die Sache nicht versucht hätte, aber da ich beruflich vorgeprägt bin durch eine Anwendung die ein durchgängiges Look'n'Feel benötigt das sich mit Standardkomponenten nur unzureichend abdecken lässt, dann stößt man mit GUI-Buildern sehr schnell an die Grenzen.
Weiterhin entspricht der Code nicht meinen Vorstellungen was für mich ein klares Minus ist.
In ein paar Jahren werden die GUI Builder noch ein paar Nummern besser sein, bis dahin bleibe ich bei Handarbeit.

 

[Daniel_L]

Ich denke über den Punkt GUI-Builder kann man sich immer streiten. Ich persönlich bevorzuge auch meine GUI selber zu erstellen, auch wenn das am Ende im Normal etwas mehr Aufwand mit sich bringt. Mir ist der Vorteil, dass der Code meinen Vorstellungen (und vor allem unseren Programmiervorgaben) entspricht wichtiger als das schnell Zusammenklicken. Mal abgesehen davon, dass ich wahrscheinlich länger bräuchte den erzeugten Code an unsere Programmierrichtiglinien anzupassen, als ich brauche das ganze gleich selber zu schreiben.

Vielleicht ist auch hier der Einsatzbereich entscheidend: Für mich als einzelner Hobbyprogrammierer ist es weniger wichtig, ob der erzeugte Code bestimmten Richtlinien entspricht. Aber was mich besonders am Netbeans-GUI-Builder fasziniert: Wenn man eine fertige Oberfläche ändern möchte und bspw. eine "Zeile" einfügen muss, dann werden alle anderen Componenten entsprechend des Fangrasters verschoben, man muss gar nichts mehr machen! Wer vielleicht schon mal mit dem guten, alten Power++ von Sybase (tafkas Optima++) gearbeitet hat, kann meine Begeisterung vielleicht verstehen.

 

[Daniel_L]

eine Anwendung die ein durchgängiges Look'n'Feel benötigt das sich mit Standardkomponenten nur unzureichend abdecken lässt

Könntest du da ein Beispiel geben? Ich denke da an die SwingX von SwingLabs bspw., und die Komponenten lassen sich alle im Palette Manager integrieren, sodass auch diese für den GUI Builder verwendet werden können. Gerade einheitliches, durchgängiges Aussehen ist doch eine Stärke der GUI-Builder: Immer das exakte Fangraster, an dem die Komponenten ausgerichtet werden etc. Oder meintest du was anderes?

Und zur Not lassen sich bestimmte Komponenten ja auch zusätzlich noch manuell einfügen.

 

[Wildcard]

Der Aufwand einer Integration würde nicht lohnen da der Hauptbereich des Programms ein eigenes Lightweight Zeichenframework ist.
Netbeans kommt sowieso nicht in Frage da es sich um ein Eclipse Plugin handelt.
Für Dialoge und ähnliches haben wir Basisklassen die entsprechende Borders setzen, Rahmen zeichnen, Titel und Description gesetzt bekommen und Button Funktionalität hinterlegt bekommen.
Mi ist unklar welchen Vorteil ich hier durch einen GUI-Builder erhalten würde.
Write Once Use Everywhere.
Die Arbeit um einige wenige Komponenten so auszusehen lassen wie man sie haben möchte und dort auch die Zeit zu investieren das der Code sauber ist und die Schnittstelle passt hält sich in Grenzen und zahlt sich meiner Meinung nach aus.
Mit einem GUI Builder hast du's da schwieriger.

 

[AlArenal]

Ich habe mich durch die Qualität der entsprechenden Tools (JFormDesigner, Matisse) eines besseren belehren lassen. Zuvor kannte ich im Grunde auch nur den JBuilder und den zum Absturz zu bringen, ist keine Kunst (und der war wohl lange Zeit der beste GUI-Builder).

Unsere Programme haben auch ihren eigenen Look und mit der Zeit baut man eine ganze Reihe spezieller eigener Komponenten, u.a. auch durch Integration weitere 3rd Party Komponenten. Gerade da konnte der JFormDesigner seine Stärke ausspielen und auch mit Netbeans kann ich aktuell in unserem Fall keine Konflikte feststellen.

An der Codequalität gibt es in beiden Fällen nichts auszusetzen, zumal de Code rin der Regel eh automatisch eingeklappt ist und eigentlich auch nicht zu interessieren hat (mit Ausnahme der Variablen- un dMethodennamen, aber das lässt sich alles wunderbar vorher einstellen). Wäre ich so pedantisch, dürfte ich keine JFC-Klassen einsetzen, da die oft genug auch kein leuchtendes Beispiel für guten Stil sind (und gewiss nicht den selbstgestrickten Konventionen von Hinz und Kunz entsprechen).

Nach der Einarbeitung ist ein klarer Produktivitätsgewinn auszumachen und gerade in der Frühphase eines Projekts, wo man noch mit Ideen spielt und Dinge ausprobiert, hat man mit einem GUI-Builder die Möglichkeit auch mit Kunden schnell mal ein paar Ideen zu testen.

Glaubt denn wirklich einer alle Welt würde alle Software ohne die diversen GUI-Builder entwickeln? Dann sollte man mal fragen warum es so viele davon gibt (allgemein gesprochen und nicht speziell nur auf Java bezogen).

Das der Gebrauch solcher Hilfsmittel nicht davon entbindet die zugrunde liegenden Mechaniken zu verstehen, sollte selbstverständlich sein.

 

[Wildcard]

Nach der Einarbeitung ist ein klarer Produktivitätsgewinn auszumachen und gerade in der Frühphase eines Projekts, wo man noch mit Ideen spielt und Dinge ausprobiert, hat man mit einem GUI-Builder die Möglichkeit auch mit Kunden schnell mal ein paar Ideen zu testen.

Genau da sind GUI-Builder derzeit hauptsächlich für mich angesiedelt. Hervorragend um mal eben was auszuprobieren.
Es kommt auch immer auf die Anwendung an. Bei mir eben hauptsächlich Eclipse-Plugins.
Eclipse bietet dir so viele Dialoge und Views das du fast keine eigenen Dialoge, Frames,.. mehr brauchst sondern nur vorhandenes an deine Zwecke anpassen musst.
Der Hauptbereich ist immer der Editor und der ist bei Textbasierten Anwendungen nun gar nichts für einen GUI-Builder, bei grafischen Editoren erledigen das GEF und GMF.
Auch dir mehrzahl der aktiven Mitglieder hier (soweit ich das bisher mitbekommen habe) schreibt ihren GUI Code selbst.
Ich bin zwar etwas voreingenommen, habe aber schon vor einiger Zeit den Entschluss gefasst mir bei meinem nächsten privat Projekt die Zeit zu nehmen und mich in einen GUI-Builder intensiver einzuarbeiten und mich eventuell überraschen zu lassen.

Was du beispielsweise nicht abstreiten kannst sind Erfahrungen hier im Forum:
Alice kommt mit einem GUI Problem ins Forum.
Bob bittet Alice um Code
Alice postet mit einem GUI-Builder erstellten Code
Bob und Charlie sind ratlos und überlassen Alice ihrem Schicksal.

(Richtig, ich habe gerade Kryptographie hinter mir :bae: )

 

[schalentier]

So auch wenns bisschen ot is, muss ich hier mal noch meine Senf dazugeben:

Ich schreib ebenfalls lieber GUI Code, als das ich mich mit einem GUI-Zusammenklick-Programm auseinandersetze. Mein Hauptargument dafuer ist, meinen Code kann ich wiederverwenden, zusammengeklickte GUIs nicht. Zumindest kenn ich keinen GUI-Editor, der das kann.

Z.b. hab ich ne Klasse fuer alle Dialog. Die zeigt immer ein paar Buttons, zum Schliessen, Abbrechen und Speichern. Alle Dialog erben von dieser Klasse und haben somit auch immer die gleichen Buttons, mit dem gleichen Text und dem gleichen Look. Aenderungen kann ich dann an einer zentralen Stelle machen und muss nicht alle Dialoge mit dem Editor oeffnen, bearbeiten und speichern.

In meinem aktuellen Projekt gibts mehrere Hundert Formularmasken (die teilweise sehr aehnlich sind). Die erben sinnigerweise auch voneinandern, so dass ich (bzw der jeweilige Entwickler) nur die tatsaechlichen Aenderungen an der Maske schreiben muss. Kann ein GUI Editor sowas? Also von einem Dialog erben?

Zudem bin ich verfechter des Prinzipis, sowenig wie moeglich Tools im Entwicklungsprozess einzusetzen. Denn jedes zusaetzliche Tool bringt potentiell neue Probleme. Was mach ich, wenn im GUI Editor irgendwas nicht so klappt, wie ich das will? Im erzeugten Code rumwuehlen und aufpassen, dass dieser nicht beim naechsten Start des GUI Editors ueberschrieben wird...

Ein mMn guter Ansatz ist bei IntelliJ's GUI Editor zu sehen (auch wenn ich den nicht wirklich verwende). Dort wird das GUI-Layout in einem extra File gespeichert und dient nur und ausschliesslich dem Zusammensetzen der Swing Komponenten. Man hat dann also Zugriff auf alle Buttons, Panels, Tabellen, etc. und kann damit normal arbeiten, wie auch ohne GUI-Editor. Tjo, aber vererben kann man dennoch kein Layout...

 

[Wildcard]

Ein mMn guter Ansatz ist bei IntelliJ's GUI Editor zu sehen (auch wenn ich den nicht wirklich verwende). Dort wird das GUI-Layout in einem extra File gespeichert und dient nur und ausschliesslich dem Zusammensetzen der Swing Komponenten. Man hat dann also Zugriff auf alle Buttons, Panels, Tabellen, etc. und kann damit normal arbeiten, wie auch ohne GUI-Editor.

Damit kann ich mich auch viel eher anfreunden als mit dem 'grauen Code' in Netbeans, denn ich sehe das gleiche Problem:
Was ist wenn es mal nicht so tut wie es soll?
Den Code in Eclipse importieren damit man ihn editieren kann und dann auf einem Haufen nicht wartbaren Codes sitzen? Toll :toll:

 

[AlArenal]

Ich schreib ebenfalls lieber GUI Code, als das ich mich mit einem GUI-Zusammenklick-Programm auseinandersetze. Mein Hauptargument dafuer ist, meinen Code kann ich wiederverwenden, zusammengeklickte GUIs nicht. Zumindest kenn ich keinen GUI-Editor, der das kann.

Was verstehst du unter "wiederverwenden"? Ich kann meine "zusammengeklickten" UIs ebenso in rein handgeschtricktem Code verwenden wie jeden anderen Code auch.

Z.b. hab ich ne Klasse fuer alle Dialog. Die zeigt immer ein paar Buttons, zum Schliessen, Abbrechen und Speichern. Alle Dialog erben von dieser Klasse und haben somit auch immer die gleichen Buttons, mit dem gleichen Text und dem gleichen Look. Aenderungen kann ich dann an einer zentralen Stelle machen und muss nicht alle Dialoge mit dem Editor oeffnen, bearbeiten und speichern.

Und wo ist nun das Problem? Du hängst deine selbstgeschrieben Klasse im GUI-Builder deiner Wahl in die Palette und fertig.

In meinem aktuellen Projekt gibts mehrere Hundert Formularmasken (die teilweise sehr aehnlich sind). Die erben sinnigerweise auch voneinandern, so dass ich (bzw der jeweilige Entwickler) nur die tatsaechlichen Aenderungen an der Maske schreiben muss. Kann ein GUI Editor sowas? Also von einem Dialog erben?

Gegenfrage: Wäre es nicht siniger deine Wissenslücke zu füllen, ehe du sie als Argument für Pro oder Contra benutzt?

Zudem bin ich verfechter des Prinzipis, sowenig wie moeglich Tools im Entwicklungsprozess einzusetzen. Denn jedes zusaetzliche Tool bringt potentiell neue Probleme. Was mach ich, wenn im GUI Editor irgendwas nicht so klappt, wie ich das will? Im erzeugten Code rumwuehlen und aufpassen, dass dieser nicht beim naechsten Start des GUI Editors ueberschrieben wird...

Es gibt auch Leute für die sind Reißverschlüsse ein Zeichen von Hochmut, die benutzen nur Knöpfe...

Wenn ich Angst vor Neuerungen habe, bin ich doch im falschen Job gelandet. Und zielsicher argumentieren kann man erst, wenn man aus der Praxis heraus weiß wovon man spricht.

Ein mMn guter Ansatz ist bei IntelliJ's GUI Editor zu sehen (auch wenn ich den nicht wirklich verwende). Dort wird das GUI-Layout in einem extra File gespeichert und dient nur und ausschliesslich dem Zusammensetzen der Swing Komponenten. Man hat dann also Zugriff auf alle Buttons, Panels, Tabellen, etc. und kann damit normal arbeiten, wie auch ohne GUI-Editor.

Das macht Netbeans nicht anders...