Also um eine pure OOP Sprache zu lernen, die nicht so ein Muell ist wie Java (Lizenztechnisch gesehen) solltest du dir mal Ruby ansehen ;)
mfg
c.
Druckbare Version
Also um eine pure OOP Sprache zu lernen, die nicht so ein Muell ist wie Java (Lizenztechnisch gesehen) solltest du dir mal Ruby ansehen ;)
mfg
c.
von Ruby habe ich auch schon viel gutes gehört. Es ist aber wohl eher mit Perl vergleichbar. Wobei es viel besser sein soll weil die "schlechten Konzepte" von Perl nicht übernommen wurden und das OOP Prinzip sehr strikt umgesetzt wurde.Zitat:
Original geschrieben von sagi
Also um eine pure OOP Sprache zu lernen, die nicht so ein Muell ist wie Java (Lizenztechnisch gesehen) solltest du dir mal Ruby ansehen ;)
Ruby zu lernen steht auch ganz oben auf meiner ToDo Liste!
Dass hier noch einer weiss, was Puschen sind :) Aus NRW, oder?Zitat:
Original geschrieben von axeljaeger
auch bis das Programm mal in die Puschen kommt,
Na ja, ich habe vor zwei Monaten mit data crunching in Perl angefangen. Es gibt also auch Ausnahmen ;)Zitat:
Original geschrieben von axeljaeger
dauert ewig. Ich gehe mal davon aus, das man für den Anfang eher GUI programmiert, wo das Programm 99% der Zeit auf Eingaben des Benutzers wartet und nicht ein Programm, was eine Woche läuft, um irgendwas auszurechnen. Da würd ich aber erst recht kein Java nehmen. Python mit Qt kann man vielleicht ein bißchen mit VB unter Windows vergleichen: GUI schnell, da in C++ programmiert, Ausführungsgeschwindigkeit nicht so toll, aber ausreichend.
Samsara
Edit: diese ewige Formatierung... *seufz*
Ja,Zitat:
Original geschrieben von Bluesm@n
Dieser Punkt hat mich bisher auch interessiert. Bei manchen Java Programmen die ich bisher gesehen habe, war die GUI ein graus und IMHO zum Teil sehr träge.
Also ist es auch möglich mit Java/QT oder Java/gtk zu arbeiten?
es gibt Bindings für beides. Allerdings weiss ich nicht wie der Entwicklungsstand ist und so...
ausserdem gibts noch SWT :)
MfG Peschmä
Stimmt, man kann Java zusammen mit Qt verwenden, aber warum sollte man? Man hat immer noch den Nachteil, das Java nicht in die Puschen kommt. Außerdem denke ich mal, das PyQt mehr verbreitet ist, als Java/Qt. Außerdem fällt das kompilieren weg. Du zählst die mangelnde GUI-Performance als den einzigen Nachteil von Java auf. Das ist aber ein erhbelicher Nachteil. Da hat sich auch schon eine norwegische Ölbohrfirma auf den Seiten von Trolltech geäußert.
Edit: War SWT nicht dieses JavaToolkit, wo man ganz Java-Un-Like selbst die Garbacecollection übernehmen musste?
... neben Startzeit und Arbeistsspeicherverbrauch
wie du schon gesagt hast: Die einzigen - ich hab nie was von unerheblich gesagt.
Zudem habe ich noch SWT erwähnt. Das kann man - genau wie JavaQt (vermutlich) und JavaGtk (sicher) - auch mit GCJ kompilieren. Dann fällt auch das Startzeitargument ins Wasser
MfG Peschmä
Oh, da bringt jmd. das Argument der nativen Kompilierung. Das hat aber nicht mehr viel mit Java zu tun.Zitat:
Original geschrieben von peschmae
Das kann man - genau wie JavaQt (vermutlich) und JavaGtk (sicher) - auch mit GCJ kompilieren. Dann fällt auch das Startzeitargument ins Wasser
Nicht jemand sondern ich. ;)Zitat:
Original geschrieben von axeljaeger
Oh, da bringt jmd. das Argument der nativen Kompilierung. Das hat aber nicht mehr viel mit Java zu tun.
Wieso hat das nicht mehr viel mit Java zu tun? Java ist ne Programmiersprache!
Ob ich das jetzt native oder nicht native kompiliere ist egal (vor allem dem Anwender).
Du hast eben die Wahl und kannst ohne Mehraufwand auch beides haben. Wenn du Tempoprobleme hast dann lohnt sich das schon. Sonst eher nicht, weil man damit die absolute ("compile once - run anywhere") Plattformunabhängigkeit verliert.
MfG Peschmä
Hm, wenn ich Tempoprobleme habe, benutze ich kein Java. Es ist ja nicht nur die mangelnde Performance, die mich aufregt, es ist auch die im Vergleich zu Qt schlechte Klassenbibliothek. Wenn ich da immer "Hörklassen" erstellen muss, um Events abzufangen, habe hinterher entweder tausend Dateien, die irgendwie Klassenname$#.class heißen, oder ich verlege hunderte von Referenzen.
Und wie lässt sich damit arbeiten? Was bietet SWT für Möglichkeiten?Zitat:
Original geschrieben von peschmae
ausserdem gibts noch SWT :)
MfG Peschmä
na und. Die sind mir dann egal. Für n jar mach ich das eh mit *.class und da sind die dann auch dabei...Zitat:
Original geschrieben von axeljaeger
...entweder tausend Dateien, die irgendwie Klassenname$#.class heißen, oder ich verlege hunderte von Referenzen.
MfG Peschmä
Ist nicht ganz so leicht wie Swing. Das Event-Konzept wurde übernommen.Zitat:
Original geschrieben von Bluesm@n
Und wie lässt sich damit arbeiten? Was bietet SWT für Möglichkeiten?
Eigentlich recht unproblematisch wenn du den Einstieg mal geschafft hast (habe als Maturarbeit n Tutorial dazu geschrieben :)) aber Java-Kenntnisse werden vorausgesetzt.
Vorteil hauptsächlich die möglichen Toolkits, auf denen SWT aufsetzt (Win32-Api auf Windows - schnell, Gtk auf Linux - langsam, Motif auf Linux - hässlich, Carbon auf Mac, Fox auf Win und Linux - schnell aber noch nicht ganz fertig) - also so eine Art meta-Toolkit im Stil von WxWindows.
Toll ist einfach das immer-native Look and Feel (wenn du aber leider auch alle Plattformen schnell mal probieren solltest bevor du das zeugs verteilst - die Implementierungen sind nicht 100% konsistent, nur etwa 98%)
Möglichkeiten?
Eigentlich alles was ich bisher brauchte. Was konkretes?
HTML in jedem Widgets wie bei Swing gibts natürlich nicht.
MfG Peschmä