ARCHIV 1999-2006

ARCHIV :: # 3655

Jaaaaaavaaaaaa

GUI-Gegähne

Autor: thyl - Datum: 15.04.2005

In diesem Artikel äußert sich der Programmierer Bill Bumgarner skeptisch zu Java auf dem Desktop. Obwohl er eigentlich ein bisschen die Meinung eines anderen wiederkaut (tun wir das nicht alle?), ist der Beitrag vielleicht deswegen interessant, weil Bumgarner anscheinend ein alter WebObjects-Programmierer ist, der dann rasch zu Java gewechselt ist. D.h., er dürfte Erfahrung sowohl in der Programmierung von ObjectiveC als auch Java besitzen und weiß damit, wovon er redet (im Gegensatz beispielsweise zu mir).

Er meint, die kleinen Verzögerungen, die das Laufzeitmodell von Java bei jeder Aktion hat, wären für ein GUI-orientiertes Programm in ihrer Kumulation problematisch, genau wie die "Kompromiss-GUI", die sich aus der prinzipiellen Portabilität von Java ergibt.

Das ist nicht gut für Apple. Ich glaube, Apple hat damals Java mit ins Portfolio aufgenommen, weil es einfach zu wenige ObjectiveC-Programmierer gab, im wesentlichen nur alte NeXTler. Und damit ist das Progrmmiermodell für den Mac ein etwas eingekeilt zwischen
-Carbon, leicht veraltet und nicht so funktional wie Cocoa
-ObjectiveC für Cocoa, Toll, aber begrenzte Programmiereranzahl, und
-Java für Cocoa, das Perfomance-Probleme hat.

Und damit rufe ich allen Programmierern zu: Lernt ObjectiveC

Kommentare

@Daniel

Von: njyo | Datum: 15.04.2005 | #1
LoCal meinte dies wohl eher rhetorisch... klar bringt man alles mit C/C++ her, was man mit Java herbringt, doch die Frage ist ja auch das wie einfach und wie schnell... und da hat Java hin und wieder (oder auch öfters) Vorteile gegenüber C/C++.

Ausserdem stimmt dein Argument nur, wenn es auf die Programmierung bezogen ist - was die nahestehende Option ist - wenn man jedoch mit dem Entwicklungsprozess, Teamstrukturen, etc. argumentiert, ist seine Aussage noch nicht widerlegt. ;)

_W

@Mechaniker

Von: LoCal | Datum: 15.04.2005 | #2
1. Java ist nicht lahm... mittlerweile kann es teilweise sogar mit C mithalten.
2. Es gibt sachen, die kriegst du nicht mit C/C++ hin...

@njyo

Von: LoCal | Datum: 15.04.2005 | #3
SWT ist nicht pure Java..

Bitte mal
hier:http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html
und in kurz hier: [Link]

lesen.

Zwar ist die implementation in Java.. soweit stimmt das schon.. aber es wird auf systemeigene APIs (die meist in C gehalten sind) zurück gegriffen.. darum funzt das ganze nur wo entsprechende Interfaces vorhanden sind...

Hallo ?

Von: Nobody | Datum: 15.04.2005 | #4
Wo ist der Bus mit den vielen Leuten die das Interssiert ?

@LoCal

Von: njyo | Datum: 15.04.2005 | #5
Ok, true... vergessen "nicht pure Java""

Doch bestehen die OS-abhaengigen Anbindungen auf den meisten wichtigen Systemen. :)
Daher der einzig wirklich wahre Weg fuer sinnvolle Java-GUIs.

_W

@LoCal

Von: Daniel | Datum: 15.04.2005 | #6
Zu 1): Java ist inzwischen wirklich performant implementiert (nicht am Mac, finde ich :-( ). Trotzdem wird Java andere Sprachen (ohne GC) niemals einholen können, wenn die anderen Sprachen vergleichbar gut compiliert werden. Der Grund liegt auf der Hand: GC ist keine einfache Aufgabe. Selbst wenn sie einfach wäre, müßte sie dennoch (zusätzlich) getan werden:

Aufwand(Problem)+Aufwand(GC) > Aufwand(Problem).

Zu 2): Wenn Du mit "Du" Mechaniker persönlich meinst, dann könnte es stimmen (ich weiß nicht, wie gut Mechaniker programmieren kann), aber allgemein stimmt das nicht.

Es gibt keine Problem in der Informatik, das in Java lösbar ist, in C/C++/Pascal/Assembler aber nicht.

Einfacher Beweis: Man kann einen Java-Compiler und eine Java-Laufzeitumgebung in C schreiben. Also kann man jedes Problem, das in Java lösbar ist, auch in C lösen, denn das entstandene System löst das in Java formulierte Problem.

@LoCal

Von: njyo | Datum: 15.04.2005 | #7
Ok, XCode fuer Java habe ich noch nie probiert und ich nehme an, dass es ganz OK ist. Doch unterstuetzt es ebenso Inline-Code-Checking und die ganzen Refactoring Tools? DAS ist mein Problem, was ich mit XCode habe. ;)

ich gebe es zu, dass mein Programmierstil eine Mischung aus design-first und evolutionaerem Programmieren ist und ich daher auch viel mit Refactoring beschaeftigt bin und das ist einfach nur umstaendlich, besonders wenn man so wie in ObjC die Methoden-Schnittstellen in zwei Dateien umaendern muss und nicht so wie bei Eclipse die Fehler gleich angezeigt bekommt. :(

Ich weiss, dass XCode 2 auf dem Weg ist. Ich habe es nicht getestet, doch so wie ich die Werbung dafuer verstehe haben sie den meisten Wert auf grafisches Klassendesign gelegt. Finde ich grundsaetzlich cool, doch frage ich mich, ob das dann auch round-trip-development (diagramm machen - code generieren - code abaendern - diagramme updaten - diagramme aendern...) leicht machen. Naja, darueber sollte man wohl wegen NDAs erst in 15 Tagen reden... ;)

Happy developing,
_W

@ionas

Von: njyo | Datum: 15.04.2005 | #8
Die Eclipse GUI IST pure Java (SWT). Das einzige wirklich schoene GUI Toolkit fuer Java. Leider auch der Grund, warum Eclipse am Mac etwas langsam ist.

_W

@thomm

Von: njyo | Datum: 15.04.2005 | #9
Ich sagte nicht, dass ObjC schlecht sei, oder so. Ich denke, dass ObjC eigentlich ganz und gar voll in Ordnung ist... in vielen Bereichen Java ueberlegen. Doch die Entwicklungsumgebungen sind einfach nicht mit Java (Eclipse, IntelliJ, NetBeans) vergleichbar und das ist ein grosses Manko, speziell fuer die "neuere generation Entwickler" (wie die MG sie so treffend vor ein paar Tagen bezeichneten), die nicht mit Emacs arbeiten, die eine IDE mit voller Unterstuetzung von Refactoring, Code-Navigation usw. wollen. Da ist XCode einfach nicht so weit, aus verstaendlichen Gruenden.

Das andere ist, dass ich ObjC zum teil etwas haesslich finde (da ich Purist bin). Daher finde ich es eigentlich toll, dass es eben public header Files gibt, doch warum muessen diese auch die Members beinhalten, etwas was man ja eben eigentlich durch Data Hiding verstecken moechte....

_W

Nochwas

Von: thomm | Datum: 15.04.2005 | #10
Wer mal etwas Cocoa "ansehen" will, kann ja mal
bei
[Link] die kleinen Programmierbeispiele (Bezierpfad, Taschenrechner, URL-auslesen usw.) durchgehen

oder auch einfach den Währungskonverter von Apple, einmal mit normalem MVC und dann mit Bindings gemacht

Gruß

Cocoa @thomm

Von: Haiko | Datum: 15.04.2005 | #11
Klar - Cocoa-C ist vielleicht cool, aber der Mac-Markt ist einfach zu klein. Und mit Java kriegt man nahezu alle Plattformen.

@thomm

Von: roser | Datum: 15.04.2005 | #12
Genau. Ich will nichts plattformübergreifendes programmieren. Ich habe aber keine richtige Ahnung von OOP - ObjC und das alles in Verbindung mit XCode oder anderen Sachen. Ich bin DAU in dem Thema und NICHT stolz darauf. Da ich das ganze aber nicht beruflich mache, sollte es halt möglich sein, das zu lernen VON ANFANG AN!!!!! Und die Möglichkeit gibt es nicht, und damit auch weniger Programme.

JAVA ist LAAAAAAAAAAAAAAAAAAAHM

Von: Mechaniker | Datum: 15.04.2005 | #13
und zwar auf allen Systemen. C++ ist die wahre Sprache und wenn man Kenntnisse in C++ hat, dann kann man auch ObjC und andere C-Sprachen. Also nicht herumjammern, sondern mal ObjC anschauen.

Also

Von: thomm | Datum: 15.04.2005 | #14
bitte!

Was soll denn dieses Javagelobe über den Klee?

Cocoa, also das von Apple um etliche Frameworks bereicherte ObjectiveC ist Java (mit Ausnahme der Plattformabhängigkeit) um Größenordnungen überlegen!
Konsequentes MVC (also Trennung von Modell View und Controller) ist mit ein Grund dafür, weshalb z.B. die iLife-Programme so "abrocken".
Für das relativ neue Binding in Cocoa gibt es überhaupt nichts Vergleichbares in Java, auch nicht im OpenSource-Projekt GnuStep!

Ich kann wegen NDA noch nicht genau über z.B. das Funktionieren von CoreData schreiben, aber wer sich mal bei Apple die schon vorhandene Beschreibung ansieht, der bekommt eine Ahnung davon, was da abgeht.

Bezüglich Codevervollständigung: Ist auch in der aktuellen Version von Xcode drin, jedenfalls habe ich noch nicht bemerkt, dass das ein kleines grünes Männchen unterm Tisch für mich macht, während ich programmiere! :-)

@ionas

Von: Haiko | Datum: 15.04.2005 | #15
SWT ist kein pure Java, aber das m.E. egal. Es gibt das für die wichtigen Plattformen und man kann bequem in Java programmieren und muss sich nicht mit C rumärgern.

Markt für ObjC zu klein?

Von: tinbert | Datum: 15.04.2005 | #16
Fein, dass der Markt so klein ist! Ich bin seit NeXTSTEP 2.0 ObjC-Programmierer, habe zwischendurch zwangsweise *alles andere* programmiert, aber ObjC schlägt immer noch und immer mehr alles andere. O.K. Smalltalk ist tatsächlich noch netter zu programmieren, da das gesamte System offen vor einem liegt und man alles, aber auch wirklich alles anschauen, tunen und auch kaputt machen kann.
Cocoa ist das Zauberwort, da steckt die Power im OS X und kommt mir jetzt nicht mit Java-Bridging.
Ja, es gibt Programme, denen man ihr Java-Herz nicht ansieht (z.B. Acquisition) und es gibt Cocoa-Programme, die Rotz sind.

Und richtig, der Markt ist klein, aber da sage ich nur: fein! Ich habe auf diesen Moment hin gedürstet, dass sich Mac OS X im Mainstream verbreitet und meine Fähigkeiten gebraucht werden, und da bin ich mir doch ziemlich sicher, dass da die Morgendämmerung ansteht.

Zu XCode 2 habe ich noch keine Meinung, aber es ist richtig, dass XCode sehr viel bei anderen IDEs (integrated development environment) lernen kann. Ich würde z.B. VisualAge (for Java) vorschlagen. DAS nenne ich eine IDE, mit integrierter Versionsverwaltung und vielen Goodies, die es sonst nur bei Smalltalk gab/gibt. Der InterfaceBuilder sucht allerdings seit 15 Jahren seinesgleichen und schlecht ist XCode nun wirklich nicht.

Fazit: ich bin verdammt froh, dass man mit Objective-C endlich Geld verdienen kann und ich mich nicht mit diesem C++-Geraffel rumschlagen muss. Ich muss allerdings zugeben, dass .NET eine prima Alternative zu sein scheint, aber auch C# ist kein Java, eher ein SmalltalkJavaObjectiveC.

@niyo

Von: Daniel | Datum: 15.04.2005 | #17
OK, so kann man das sehen.

Das Problem an C++ ist, daß man es relativ gut können muß, um damit ernsthaft arbeiten zu können. Java ist da toleranter, wobei es da auch nicht schadet, wenn man es wirklich beherrscht ...

Sorry, wenn ich da immer etwas forsch reagiere, aber die Java-Verfechter kommen mir einfach zu oft mit dem Argument, daß Java ja eigentlich genauso schnell wäre wie C. Teilweise habe ich auch schon gehört, Java wäre besser zu optimieren als C und daher bald sogar grundsätzlich schneller als jedes native Programm. Außerdem ist das bei den heutigen (oder zumindest bei den morgigen) Prozessoren sowieso alles so egal.

Nachtrag @ local

Von: Sven Janssen | Datum: 15.04.2005 | #18
Was bekomme ich mit C und C++ nicht hin was ich in Java machen könne.
Das würde mich wirklich brennend interessieren. Ich zweifel dies nämlich arg an und dreh den Spieß herum. Treiber mit Java?
und performancmäßig wird Java nie einer nativen Sprache das Wasser reichen können. Das klappt schon von der Architektur nicht.

Sven

@njyo

Von: Sven Janssen | Datum: 15.04.2005 | #19
> der Entwicklungs-Prozess mit ObjC einfach
> nervig: Compile-Zeiten, imports, header/
> implementation Trennung

Xcode ist nicht der Weißheit letzter Schluß, aber Cocoa hilft einem extrem beim erstellen von Programmen. Ich komme von Delphi und da ist man noch ne Ecke verwöhnter als bei Java , aber Cocoa hat es mir echt angetan.
Sorry, aber da kommt Java bei weitem nicht heran.

Und IDE / Sprache sollten wir schon trennen. Xcode und der IB sind wirklich nicht das gelbe vom Ei, aber die Sprache Obj-C und Cocoa ist ne super nette Sache.

Meinereiner hat nun in Basic, Delphi, Pascal, C, Cobol, Java und Obj-C programmiert.
Von der Sprache ist Cocoa das beste, von der IDE klar Delphi ( bis 6 ).
Aber Java und die IDEs sind (und waren) immer "far away from usable".

Sven

@Sven

Von: njyo | Datum: 16.04.2005 | #20
Klar sollten wir Sprache und die Entwicklungsumgebung nicht vermischen. Ausserdem sollten wir auch nicht Cocoa mit ObjC gleichstellen, weil das das selbe wäre, wie statt C++ STL zu sagen (siehe auch hier "Conclusion": [Link] Cocoa ist das, was ObjC eine tolle Sprache macht. Ich habe oben auch nie behauptet, dass ObjC wirklich schlecht sei. Sie hat jedoch einige Ecken, die mir nicht gefallen. Und die liegen nunmal nicht nur an der Sprache (Interface/Implementation) sondern auch am Enwickungsprozess (Compile-Zyklen). Toll ist jedoch vor allem die Dynamik der Sprache. Daher habe ich ja in Frage gestellt, ob es wirklich sinnvoll ist, alle Entwickler auf ObjC zu hetzen, ob es nicht vielleicht bessere Alternativen gäbe. (Ich denke da an Python). Performance ist in dieser Frage jedoch ein gutes Argument für ObjC.

Wegen der IDE: Es ist schon Ewigkeiten her, dass ich Delphi verwendet hatte (in der Schule) und ich weiss nicht mehr welche Version (wohl so Dephi 4). Doch kann ich mich noch recht stark an die point-n-click Programmierung der damals (nicht, heute schon) trivialen Programme ;) erinnern. Das System ist ganz OK, sofern es eben auch möglich ist, auf diese GUI-Click-Programmierung zu verzichten und einfach und schnell den Code schreiben kann. Das ist etwas, das mit Eclipse phänomenal einfach geht. Besonders Refactoring ist dort extrem einfach und schnell. Versuch Mal in ObjC nur den Klassennamen zu ändern, weil du daraufgekommen bist, dass dieser irgendwie falsch ist. Dann musst du mit Suchen/Ersetzen loslegen. Noch schlimmer: eine Methodenschnittstelle abändern. Viel Spass. Ändern, suchen, {compilieren, weitere Fälle suchen}[0...n] DAS ist etwas, das Xcode&IB noch brauchen. IB ist toll, gebe ich zu, aber eben ist der Prozess auch noch nicht ideal - oder ich habe eine andere Vorstellung von dem, als die Leute bei Apple.

Aus diesem Grunde, stelle ich den Aufruf "lernt ObjC" in Frage. Sprache ist akzeptabel, Toolkits sind toll aber IDEs sind schlecht. Da sollte man doch bessere Kombinationen finden können. ;) z.B hoffentlich in ein paar Jahren mit PyObjC...

_W

Evaluierung von Entwicklungssystemen

Von: pm | Datum: 16.04.2005 | #21
Die Anzahl der neuen Programmiersprachen ist geradezu inflationär von Dylan, Halskel, Java, Python um nur ein paar zu nennen. Wenn es aber darum geht wirklich effizient Code abzuliefern und zu generieren und das auch noch termingerecht kommen auf einmal Sprachen zum Vorschein die in den 50iger - 70iger Jahren entwickelt wurden. Lisp, Smalltalk, Scheme, C.
Hier stellt sich intressanterweise irgendwann die Frage wieviel abstraktion ist sinnvoll und warum programmieren immer noch Legionen realtiv gut lesbaren Cobol Code auch wenn nicht auf der Mac Umgebung.
Was verändert sich zwischen ObjC von Next und der Weiterentwicklung von Apple. Zuerst einmal, dass Apple bis heute keine Trainings anbietet. (Hillegass ist die Ausnahme, aber als NeXT Mitarbeiter, der die Dokumentation damals geschrieben hat ist er geradezu prädestiniert für den Job)
Bis zum heutigen Tag habe ich von Apple kein XCode Training gesehen (D-A-CH)
Bei Next war die Entwicklungsumgebung die Stärke auch für sehr leistungsfähige Applikationen.
Borland ist eine Firme die immer eingekauft hat, dies sieht man auch allen Produkten an, die sie je verkauft haben.
Die Situation Unix Code von Dec, HP, Solaris Varianten in OS X Projekte umzusetzen ist aus meiner Sicht eigentlich vorhanden. Was es aber schwermacht sind die wirklich fehlen grossen Entwicklungstools. Hier muss Apple mal richtig Geld investieren nur schon leistungsfähige Konvertierungstools würden dramatisch helfen mittelfristig.

Was in Java so geht....

Von: LoCal | Datum: 16.04.2005 | #22
.... also ich habe mich etwas falsch ausgedrückt.. klar geht alles was in Java geht auch mit C/C++ (aber auch umgekehrt.. und für die Treiber.Sache.. es gibt ein natives JavaOS!) Aber wenn ich zum Beispiel Sachen wie Tomcat oder JBoss nehme... die Sachen sind zwar theoretisch auch mit anderen Sprachen möglich... aber nur durch Java sind sie ordentlich nutzbar und wartbar.

@LoCal Natürlich gibt es Alterntavien zu Java Application Server

Von: tjp | Datum: 16.04.2005 | #23
Da wäre zum Beispiel IBMs Visual SmallTalk zu erwähnen, daß steht dem ganzen Java Schlonz in der Funktionalität in nichts nach. Für C++ gibt es ähnliche umfangreiche Klassenbibliotheken, beides kostet Geld. Aber WebLogic bzw. WebSphere ist auch nicht ohne.

Die Masse an Java Programmierer ist nicht unbedingt der Software Wartbarkeit förderlich. Ich kenne eine Programmiersprache (Ada), die ganze gezielt darauf optimiert wurde, wartbare Software zu schreiben. Auch Java ist in dieser Hinsicht ein großer Rückschritt zu Ada.

Aber C, C++, C#, Java haben eines gemein, sie fördern mit ihrer Syntax den schlechten Programmierstil, und des wegen sind/waren diese Programmiersprachen so beliebt. Schlechte Programmierer brauchen Programmiersprachen, die sie nicht von Fehlern abhalten, anderfalls fielen ihre Defizite auf.

Hüstel...

Von: flynn | Datum: 16.04.2005 | #24
Mal so in die Runde gefragt... Hat sich eigentlich jemand die Mühe gemacht mal den Artikel von bbum (der nun wirklich nicht irgendwer ist), bzw. die Analyse von Carmack zu *lesen*? Oder wird hier nur um des Java-trollens willen gepostet?

"For UI applications, the differences between platform and UI philosophy mean that WORA also yields a user experience that is alien to the platform." -- Mehr könnte ich einer Zusage nicht zustimmen. Gerade Mac User sollten verstehen, dass Cross Platform UI Applikationen eine Marketing Lüge erster Klasse sind.

noch so einer!

Von: thomm | Datum: 18.04.2005 | #25
"Ich meine seit Bill Bumgarner für Apple arbeitet, sagt es sich natürlich bedeutend leichter, dass Cocoa das einzig wahre ist. Aber Java hat soviele Vorteile..."


Irgendwie geht mir Dein Geseier etwas auf den Geist!
Wahrscheinlich bist Du ja erst seit WO 5.2 dabei also noch eher in dieser Beziehung ein Jüngling ;-)

Wofür nimmt man den wohl WO?! Wohl nicht, um kleine schnelle Desktopanwendungen zu schreiben! Oder hab ich was verpaßt und sämtliche iLife-Anwendungen, FinalCut.... Shake, Motion, Modo, Big Chess.... wurden alle in Java geschrieben? :-) Doch wohl eher nicht, denn falls man dies überhaupt hinbekommen hätte, wäre die Performance dieser Programme garantiert so lausig, dass sich jeder Dosies schlapp gelacht hätte!

WO war nicht immer Java, wurde erst mit 5.2? darauf umgestellt weil die EOF-Tools nicht mehr (im OpenStep-Projekt) weiterentwickelt wurden!
Ich verrate Dir wahrscheinlich etwas völlig Neues, wenn ich Dir jetzt schreibe, dass Apple NeXT gekauft hatte und NeXTStep(aka OpenStep) die Basis für MacOS X war.
Ein Grund dafür war die Entscheidung Apples, die PC-Seite nicht mehr weiterzuentwickeln, weshalb die Umstellung auf Java von OpenStep logisch war!

Zusammenfassend kann man sagen: Java hat soviele Nachteile :-P, je nachdem was man braucht!!

Natürlich hat es in bestimmten Bereichen auch Vorteile :-)))

@thomm

Von: Haiko | Datum: 18.04.2005 | #26
Ich kann kein ObjC - das Beispiel ist aus der Entwicklerforums-Seite rauskopiert. Und egal ob's nun läuft oder nicht, die Syntax ist gruselig.
Wenn Du mal größere Softwareprojekte durchgeführt hättest wüsstest Du, dass Lesbarkeit des Programmcodes inzwischen wichtiges ist als 10% mehr Performance wegen Compilieren. Aber Deine Erfahrungshorizont ist scheinbar so beschränkt wie Dein Vokabular.

lernt ObjC?

Von: njyo | Datum: 15.04.2005 | #27
Nun, als Informatik-Student, der von Java kommt und nun gerade durch die "lernt ObjC" Phase geht kann ich nur fragen, ob das wirklich sinnvoll ist. Verglichen mit Java ist in meinen Augen der Entwicklungs-Prozess mit ObjC einfach nervig: Compile-Zeiten, imports, header/implementation Trennung (die nicht schön gemacht wurde und durch kein Tool richtig unterstützt wird), Garbage Collection. Wer eine weile mit Eclipse und Java verwöhnt wurde tut sich mit der Entwicklung in ObjC anfangs schwer (generalisiere ich nun jetzt Mal). Ich muss jedoch sagen, dass ich die GUI-Programmierung in ObjC (bzw. Cooca) echt toll finde, einfach und elegant. Auch wenn die Tools IB&XCode in meinen Augen nicht imemr ideal sind.

Daher sehe ich vor allem handlungsbedarf bei Apple, endlich mal XCode richtig zu verbessern (so viel ich weiss, sind in v2.0 auch nicht die von mir gewünschten Features drinnen: z.b. Refactoring - zumindest Laut Beschreibung) und zu öffnen, sodass man selber Add-Ons schreiben kann. Zum anderen finde ich, dass Apple die PyObjC-Brigde ausbauen (helfen) sollte, und den Schwung aus dem Python Lager nutzen könnte. Allerdings bringt das das Problem, dass Python ebenso wie ObjC eine IDE auf dem Level von Eclipse fehlt. Doch die Hoffnung ist da immernoch da, dass sowas noch kommt. Dann hätte man eine schöne, elegante, einfache und mächtige Sprache mit dem tollen Cocoa Framework.

my 1.5cents.
_W

Ich bin da einfach zu alt für......

Von: roser | Datum: 15.04.2005 | #28
denn ich habe wirklich keine Lust mich durch irgendwelche englischsprachigen Bücher zu quälen. Für Java habe ich 2 toll beschriebene Bücher von Galileo und kann die auch Stück für Stück verstehen lernen (ja, ich muß auch erst mal objektorientierte Sprachen verstehen.) Z. Zt. helfe ich mir mit der Cocoa-Java-Bridge, würde auch eigentlich viel lieber in ObjC programmieren (weil schnellerer Programmablauf). Da die passenden lokalisierten Beschreibungen für a) ObjC und b) XCode fehlen ist das ein Problem und wird auch eines bleiben.

*Ach tat das mal gut*

@roser

Von: njyo | Datum: 15.04.2005 | #29
...tröste dich, die hochgelobe (englischsprachige) Literatur für ObjC von Apple oder auch anderen (Hillegass, ...) ist auch nicht wirklich besonders toll. Ich denke, du ersparst dir einige graue Haare, wenn du weiterhin Cocoa-Java verwendest. Ist das echt sooo schlecht Performancemäßig? Ich meine Java wirkt auf meinem Mac generell lahm, inwiefern ist das dann mit Cocoa noch schlimmer?

_W

hmmm, eigentlich quatsch, deine schlußfolgerung

Von: hellmachine | Datum: 15.04.2005 | #30
also, bin auch kein programmierer, aber die schlußfolgerung ist einfach nicht richtig.
so klar kann man das alles nicht trennen.
grundsätzlich sind das alles nur apis, also programmierschnittstellen, das heißt, du bist bei der entwicklung nicht für immer und ewig auf eine dieser schnittstellen festgelegt.
das ganze sieht eher so aus:
schon jetzt aber erst recht in zukunft kannst du programme schreiben, die alle diese schnittstellen nutzen.
du kannst z.b. carbon apis mit cocoa nutzen:
[Link]
du kannst auch total native java apps schreiben, die ein perfektes cocoa interface haben:
[Link]
selbst mit phyton geht das, und du merkst auf gui-ebene nix, weils einfach native ist. in welcher sprache (der von cocoa nutzbaren) der programmkern entwickelt ist, spielt fast keine rolle. es gibt für all das auch viele beispiele. z.b. ist das performanceintensive "modul8" soweit ich weiß mit einem python kern verarbeitet. auch für die java wrapper gibts viele beispiele. mir fallen nur die namen nicht ein :-(
also, keine panik. was du als dogma beschreibst, ist eher ein vorteil. immer ein perfektes cocoa gui aber ein programmkern, der von cocoa, java, carbon oder python reichen kann. der anwender merkt nix. der einzige grund, warum die großen hersteller "adobe, macromedia, microsoft..." das nicht stärker nutzen, ist die portierbarkeit. naja, und dafür ist carbon halt wirklich akzeptabel...

Also, ich weiss ja nicht ob das geht...

Von: roser | Datum: 15.04.2005 | #31
...aber wenn XCode Java nicht in Byte- sondern auch in Binärcode compilieren würde, dann hätte ich auch kein Interesse mehr an ObjC.

Schön und gut, aber ...

Von: kielmac | Datum: 15.04.2005 | #32
Ich finde ObjC auch wunderbar, und hatte mich auch schon zu Next Zeiten damit auseindersetzen dürfen.
Jedoch muß ich leider sagen der Markt für Programmierer ist für Macs klein genug, und da ist Java natürlich höchst willkommen.
Ich habe ObjC schon ewig nicht mehr angepackt, und wenn dann nur als Hobby.
Such doch mal nach ObjC Jobs, dann wirst du versthen, warum es dafür so wenig Programmierer gibt.
Für einen anständigen Job oder Projekt würde ich mich liebend gern ordentlichst reinknien ...

Java läuft auf dem Desktop!

Von: Haiko | Datum: 15.04.2005 | #33
Man braucht sich nur mal die Ecplise-Plattform anzuschauen. Da merkt man (fast) nicht mehr dass man ein Java-Programm hat, außer beim Start. Die Anwendung ist portabel und sieht trotzdem auf jeder Plattform aus wie nativ. Die immer herbeigeredeten Performance-Probleme von Java gehören m.E. inzwischen der Vergangenheit an bzw. sind auf halbwegs aktueller Hardware zu vernachlässigen.

@ Haiko

Von: ionas | Datum: 15.04.2005 | #34
Afaik ist die UI von Eclipse nicht Java, aber ich kann mich täuschen.

Shots

Von: ionas | Datum: 15.04.2005 | #35
[Link]
[Link]

stereo?

Von: mono | Datum: 15.04.2005 | #36
quadro?

Mac Entwicklerforum

Von: Kay | Datum: 15.04.2005 | #37
Wer gerne für Mac's proggt und keine Lust hat sich durch "englische" Literatur zu wälzen, der schaue mal hier vorbei. Mac OS X Entwicklerforum".

Natürlich alle anderen auch!

@njyo

Von: LoCal | Datum: 15.04.2005 | #38
Also ich benutze jetzt seit ca. 2 Jahren eclipse zur Java-Programmierung und hab mir vor 2 Tagen mal XCode angetan... also für Java, Obj-C muss ich noch lernen und werd ich auch bald tun. Jedenfalls finde ich XCode garnicht so schlecht...also die Umstellungsphase ging bei mir recht schnell... was "fehlt" sind halt einige nette Dinge von eclipse wie automatische Code-Vervollständigung oder auch automatische Korrektur, aber ehrlich gesagt bin ich mal ganz froh das nicht zu haben.. und notfalls gibbet 'F5'.
Also ich finde XCode doch ganz gut...

In sich falscher Titel

Von: ionas | Datum: 17.04.2005 | #39
GUI muss UI heissen.

Sorry (ObjC Syntax)

Von: Haiko | Datum: 18.04.2005 | #40
aber sowas:
return [[[NSString alloc] initWithData:[[[NSURL URLWithString:url] URLHandleUsingCache:NO]

erinnert mich doch fast an Lisp (wenn die ganzen Klammern rund wären). Was soll denn das heißen? Da bleibe ich doch lieber bei Java, das hat wenigstens eine halbwegs eingängige Syntax ohne kryptische Klammern etc.

@haiko

Von: thomm | Datum: 18.04.2005 | #41
Quatschkopf!!

Selbst ein REALBasic-Newbie sieht sofort, dass Dein Beispiel nicht klappen kann, wegen fehlender Klammersetzung (wahrscheinlich programmierst Du unter Java wohl so).

Macht sich natürlich gut zur Verballhornung , nicht wahr? ;-)

Java ist nun einmal lahmarschig, weil es eben nicht compiliert wird!
Bzgl. der immer wieder zierten Compilezeiten:

1. Compiliert Xcode schon Teile während des Schreibens des Codes

2. Wird nur beim ersten Mal der gesamte Code compiliert, später nur die Änderungen (außer natürlich nach einem Clean Target)

3. Weiterhin kann man natürlich bei mehreren vorhandenen Rechnern Verteiltes Compilieren (Distributed Build) verwenden

4. Kann ich während die Anwendung läuft, den Code ändern und sofort mittels compile die Änderungen sehen.....

5. Versionsverwaltung wird i.allg. jetzt mit Subversion gemacht (früher vorwiegend mit CVS)

4. Es gibt auch ein Unit-Test-Tool (OpenSource)

5. Ist mir nicht bekannt, das z.B. Categories und Posing bei Java geht (lasse mich aber gern belehren)

6. Geht in Java kein Binding wie in Cocoa (Stichwort CoreData - wa ich ruchzuck mal eben eine kleine SQLite-DB erstelle) - das MVC-Modell wird so nicht durchgezogen

7. Java - ALTIVEC ?

8. Java - CoreImage



und sooooo komfortabel ist die Java-Syntax ja nun auch nicht :-).

Wie schon geschrieben, auf Mac wieder langsamer ;-)


Cocoa ist eben Smalltalk-ähnlich


......


Es gibt natürlich noch viel an Xcode als Entwicklungsumgebung zu verbessern aber m.E. ist es Java bzw. deren Entwicklungsumgebungen schon heute um Längen voraus.

@haiko kein Sorry

Von: thomm | Datum: 18.04.2005 | #42
armseliger Wicht!

kein ObjC kennen UND kein Englisch UND keine Ahnung von Programmieren UND zuU dämlich, eine Anweisung aus einer Entwicklerforumseite vollständig zu kopieren - Du bist echt nicht zu beneiden!!


Wenn Du in der Lage sein solltest, ein Englisch-Deutsch-Wörterbuch zu bedienen, dann könntest Du ohne jegliche Programmierkenntnisse (ist ja bei Dir gegeben) lesen: "return" d.h. "gebe zurück"

"[NSString alloc]" d.h. reserviere einen Speicherbereich für einen String

"initWithData:" d.h. initialisiere mit Daten

"[[NSURL URLWithString:url] URLHandleUsingCache:NO]]" eine URL welche mit dem Stringwert der Variable url gefüllt wird, ohne den Cache zu verwenden.....



Es ist also fast Umgangsenglisch, die eckigen Klammern sind als Begrenzung des Ausdrucks (entsprechend Methoden, Werten, die verschiedene Formen annehmen können) definiert.

Auf den Punkt gebracht, Du bist einfach zu doof, wenigstens mal die Bergiffe zu lesen und läßt hier aus der Hüfte geschossenen Dünnpfiff ab!
Da Du noch nicht einmal diese primitive (unvollständige und damit natürlich automatisch falsche) Programmzeile checkst, bist Du auch zu dämlich für JAVA, wo eben die .-Notation verwendet wird, also bekommst Du allenfalls ein "Hallo Welt" programmiert :-P

Kleiner Tip für Dich Ahnungslosen, damit Du wenigstens ansatzweise eine Chance hast, die Programmierzeile zu verstehen: grundlegende Regel der Mathematik: Anzahl der öffnenden Klammern muß gleich der Anzahl der schließenden sein (egal ob rund, eckig, geschweift....) ansonsten funktioniert die Rechnung nicht!!!



Geh spielen!!!!

MacGuardians

Von: Haiko | Datum: 18.04.2005 | #43
Kann mal jemand obigen Nutzer plonken - diesen Tonfall will hier glaube ich keiner lesen.

Entschuldigung für Tonfall

Von: thomm | Datum: 18.04.2005 | #44
"Aber Deine Erfahrungshorizont ist scheinbar so beschränkt wie Dein Vokabular."

Dein unberechtigter Tonfall ist ja wohl auch unter aller Kanone. Wer im Glashaus sitzt....



Du hast in Bezug auf Cocoa keine Horizont, da Du davon absolut keine Ahnung hast. Deshalb war Dein Angriff auf mich ohne den geringsten fachlichen Hintergrund für mich ein Beleidigung!! Ich lasse mich gern eines Besseren belehren wenn ich etwas Falsche schreibe. Da Du aber nicht in der Lage bist, hier mal FAKTEN aufzuführen, solltest Du auch nicht falsches Halbwissen verbreiten.
Weiter oben hat jemand nach einem Einstieg in die Xcode-Programmierung gefragt, da sind solche dummen Kommentare von Amateuren wie Du leider einer bist für ihn wenig hilfreich!


Die Möglichkeit des Plonkens/Ignorierens von Usern (wie z.B. Dich) wäre nicht schlecht, denn mir brennen schnell die Sicherungen bei solchen geposteten Unsinn wie von Dir durch!



Also bitte: Wo bleiben denn zur Abwechslung mal DEINE FAKTEN??!!!! oder kommt nur noch heiße Luft?

@thomm

Von: Haiko | Datum: 18.04.2005 | #45
Lies mal die Beiträge oben dann wirst Du merken, dass die erste persönliche Beleidigung hier von Dir kam. Ich hatte lediglich die Syntax von ObjC bemängelt und nicht Dich persönlich, Du kamst dann im Reply mit "Quatschkopf" (persönlich) und "wahrscheinlich programmierst Du unter Java wohl so" (persönlich).

@haiko

Von: thomm | Datum: 18.04.2005 | #46
bring bloß keine Fakten, könnte schädlich sein......

verbleiben wir mal so: Ich habe nach Deiner Meinung keinen Takt, Du keine Ahnung vom Thema und wir beide schreiben :-P

Tonfall

Von: flo (MacGuardians) | Datum: 18.04.2005 | #47
So, weil mir das echt zu blöde ist, jeden einzelnen Kommentar durchzugehen, um herauszufiltern, wer nun wo genau wen beleidigt, über die Stränge schlägt oder sonstwas, eine generelle Bitte:

Ab sofort Schluss mit den Beleidigungen hier, sonst hau ich einfach alle Kommentare der Betreffenden raus für die nächsten Tage, mir scheißegal, ob er darin etwas anständiges berichtet oder bloß herumquatscht.