c++ vs. java... was hat zukunft
-
[quote="Gast++"]
lol geil schrieb:
Gast++ schrieb:
Was nützen mir apache-Links wenn ich ein Java-Paket brauche?
Wer lesen kann ist klar im Vorteil
anscheined bist du der, der nicht lesen kann:
Apache XML-RPC is a Java implementation of XML-RPC,desweiteren, seit wann braucht man für einen *client* eine serversoftware? erst reicht kein "enterprise sdk". dass man für einen *client* keinen *server* braucht sollte jemandem der weiß wie man nen c++ compiler installiert eigentlich klar sein
Deshalb soll ich mir also Apache-Pakete instalieren? Weil ich eine Client-Lösung brauche? Interessanter Ansatz!
Bist Du sicher dass Du weisst was der Apache eigentlich ist? Oder XML-RPC?
wow, du hast du ja heftig informiert. mit jedem post nehme ich dir deinen google-versuch weniger ab
Hast Du mal die Installationsroutinen von SUN, die Dich ständig auf einen fehlenden Server hinweisen, getestet bevor Dich hier zu Wort gemeldet hast ?
nein ich hab keine "installationsroutinen getestet", ich hab auch nie bei einer softwareinstallation von sun gesehen dass ein server benötigt wurde. bei welchem softwarepaket kam denn die meldung? beim jdk jedenfalls nicht - und mehr als das brauchst du für xml-rpc nicht
=> Schwafel mich bitte nicht voll mit Deinem Halbwissen!
wer hier halbwissen hat stelle ich mal in frage (das mit apache hast du ja anscheinend auch nich verstanden)
-
lisp, haskell, ocaml, erlang, smalltalk, objective c, D
-
@unreg:
wer hier halbwissen hat stelle ich mal in frage (das mit apache hast du ja anscheinend auch nich verstanden)
Bleib mal auf dem Teppich - Du gibst ja zu das SUN Paket nicht installiert zu haben; hast aber erstmal pauschal meine Aussage angegriffen...
der gleiche wie oben schrieb:
wow, du hast du ja heftig informiert. mit jedem post nehme ich dir deinen google-versuch weniger ab
..und versteigst Dich dennonch zu solchem Quatsch.
Sei's drum;
@all:
was haben wir von unreg gelernt?- es gibt ein Paket von Apache.org das mir den Leistungsumfang wahrscheinlich geboten hätte.
=> Man bruacht also Third-Party-Tools offenbar auch unter Java.
Wenn ich das Problem mit C++ lösen will muss ich eine Bibliothek installieren; lös ich's mit Java muss ich dergleichen tun. Eigentlich dachte ich immer SUN sei für Java-Lösungen zumindest eine zentrale Anlaufstelle; auch das hat sich nach dem Vorhergehenden ja relativiert.
Welchen Unterschied macht das jetzt - abgesehen davon dass ich etwas was sich "Apache-irgenwas" nennt nieamls bei (Client-)Platformverantworlichen durchsetzen könnte ?
Grüsse
*this
-
Gast++ schrieb:
@unreg:
wer hier halbwissen hat stelle ich mal in frage (das mit apache hast du ja anscheinend auch nich verstanden)
Bleib mal auf dem Teppich - Du gibst ja zu das SUN Paket nicht installiert zu haben; hast aber erstmal pauschal meine Aussage angegriffen...
meister, wenn du nicht sagst *was* du von sun installiert hast, kann ich dir nicht sagen ob ich es auch installiert hab. logisch nich?
ich hab jedenfalls die glassfish installiert, wo so eine meldung nicht kam (hätte auch wenig sinn gemacht beim glassfish)..und versteigst Dich dennonch zu solchem Quatsch.
kappier ich nich aber egal jetz
=> Man bruacht also Third-Party-Tools offenbar auch unter Java.
du kannst einen xml-rpc aufruf sowohl unter java als auch unter c++ mit den standardmittel durchführen, natürlich geht es mit externen libraries um einen großen faktor einfacher
Eigentlich dachte ich immer SUN sei für Java-Lösungen zumindest eine zentrale Anlaufstelle; auch das hat sich nach dem Vorhergehenden ja relativiert.
von sun gibt es auch einen xmlrpc stack, der aber natürlich nicht in der standard edition mit enthalten ist mangels nachfrage, sondern nur im enterprise stack. du kansnt die natürlich auch separat benutzen, siehe: https://jax-ws.dev.java.net/ und https://jax-rpc.dev.java.net/
was haben wir von unreg gelernt?
dass gast++ gerne mal einfach so losbrüllt
-
der gleiche schrieb:
Gast++ schrieb:
@unreg:
wer hier halbwissen hat stelle ich mal in frage (das mit apache hast du ja anscheinend auch nich verstanden)
Bleib mal auf dem Teppich - Du gibst ja zu das SUN Paket nicht installiert zu haben; hast aber erstmal pauschal meine Aussage angegriffen...
meister, wenn du nicht sagst *was* du von sun installiert hast.
So langsam hast Du's, glaube ich, begriffen! Du hast die ganze Zeit über ein Paket schwadroniert das Du gar nicht kennst.
was haben wir von unreg gelernt?
dass gast++ gerne mal einfach so losbrüllt
Das passiert genau dann wenn jemand einfach mal so in's Blaue hineinlabert wie Du.
von sun gibt es auch einen xmlrpc stack, der aber natürlich standard edition mit enthalten ist mangels nachfrage, sondern nur im enterprise stack.
Richtig. Also in genau dem Paket das für die Entwicklung eines simplen XML-RPC Clients völlig überdimensioniert ist. Q.E.D.
Womit wir dann wieder am Anfang wären...
Grüsse
*this
-
schlauher als du schrieb:
in der objektorientierten programmierung is jede klasse auch ein typ.
Nein. Es muss in der OOP ja noch nicht einmal Klassen geben.
ob ich mit einer bestimmten programmiersprache einen '+' operator auf eine instanz dieses types darauf anwenden kann ist lediglich ein sprachfeature und ändert wohl nix an den konzepten der objektorientierten programmierung
Sicher. Aber das ist ja nur einer der Punkte wo man sieht, das es in Java Typen und Klassen gibt und die sehr verschieden sind.
-
rüdiger schrieb:
Es muss in der OOP ja noch nicht einmal Klassen geben.
und wo kommen dann die objekte her?
-
-
pale dog schrieb:
rüdiger schrieb:
Es muss in der OOP ja noch nicht einmal Klassen geben.
und wo kommen dann die objekte her?
Die bringt der Klapperstorch...
*SCNR*
Man kann z.B. in Perl 5 objektorientiert programmieren indem man ein en Hash(aka Python: Dictionary {}, C++ STL: map<T>) geeignet ausstattet.
Beim "normalen" Weg mit Perl Objekte zu erzeugen passiert eigentlich nichts anderes; nur halt in meist einem Modul das an die Stelle einer Klasse als Instanzfabrik tritt.Grüsse
*this
-
Gast++ schrieb:
...in meist einem Modul das an die Stelle einer Klasse als Instanzfabrik tritt.
und kann die auch verschiedene objekte erzeugen oder sind die alle gleich?
sobald man die struktur von objekten bestimmen kann, hat man ja doch wieder klassen...
-
pale dog schrieb:
und kann die auch verschiedene objekte erzeugen
Das kann ein Modul durchaus; man könnte sogar die Vererbungshierarchie zur Laufzeit setzen! (Macht man allerdings i.A. nicht ohne Grund)
pale dog schrieb:
oder sind die alle gleich? sobald man die struktur von objekten bestimmen kann, hat man ja doch wieder klassen...
Andersrum : Man kann das so nutzen; aber man muss es nicht!
Man kann auch einfach in einen Hash eine Funktionsreferenz einfügen und dem (Hash)Objekt so Methoden verpassen. Dazu muss man nicht vorab eine Klasse definiert haben.
Grüsse
*this
-
irgendwie macht das eh keinen sinn mit dir zu reden. du hast auch irgendwie gar kein interesse war dazuzulernen oder so. is auch sinnlos, wenn du meine sätze nur zur hälfte liest
der gleiche schrieb:
du kansnt die natürlich auch separat benutzen
aber dass du ungern auf links klickst hab ich schon bemerkt.
ich hoffe, dass niemand mal im real life mit dir darüber reden muss, viel spaß noch beim projekt
-
pale dog schrieb:
rüdiger schrieb:
Es muss in der OOP ja noch nicht einmal Klassen geben.
und wo kommen dann die objekte her?
Schau dir zB ECMAScript an. Das ist OO aber da gibt es keine Klassen.
-
der gleiche schrieb:
irgendwie macht das eh keinen sinn mit dir zu reden. du hast auch irgendwie gar kein interesse war dazuzulernen
Du hingegen scheinst ein grosses Bedürfnis zu haben etwas "lehren" zu wollen.
Es ist nicht das erste Mal das ich erlebe dass Kritik an Java zunächst mal als Wissensdefizit abgetan wird.
Das ist nicht nur höchst einfältig sondern führt dazu dass Java in weniger Projekten eingesetzt wird als es es möglich wäre, da so keine ernsthafte Diskussion einsetzt.
der gleiche schrieb:
oder so. is auch sinnlos, wenn du meine sätze nur zur hälfte liest
der gleiche schrieb:
du kansnt die natürlich auch separat benutzen
aber dass du ungern auf links klickst hab ich schon bemerkt.
Wenn Deine Sätze einander widersprechen ("nur im EE" vs "auch separat") löse ich den Widerspreuch ökonomisch und spare - höchstwahrscheinlich überflüssige - Arbeit.
Da Du mich bereits der Lüge zu zeihen versucht hast sehe ich für anderweitige Höflichkeit keine Veranlassung mehr.
der gleiche schrieb:
ich hoffe, dass niemand mal im real life mit dir darüber reden muss
Brauch ich nicht, solange mir immer andere Spezifikationen mit einm zusätzlichen "J" im Namen genannt werden wenn ich nach der Implementierung eines Protokolls frage.
Für mich ist es unwichtig ob es "JAX-RPC" unterstützt; gefordert war "XML-RPC".
Der Begriff hingegen findet sich nicht auf den von Dir zitierten Seiten (ich hätts mir denken können).Grüsse
*this
-
rüdiger schrieb:
pale dog schrieb:
rüdiger schrieb:
Es muss in der OOP ja noch nicht einmal Klassen geben.
und wo kommen dann die objekte her?
Schau dir zB ECMAScript an. Das ist OO aber da gibt es keine Klassen.
ja, hab's überflogen.
es gibt verschiedene typen von objekten und sie haben sogar ein property namens '[[class]] "A string value indicating the kind of this object."'
die objekte werden nur nicht erzeugt wie etwa in Java, recht seltsames zeug, Javascript eben...
-
An dieser Stelle wird mir das dann doch (auch endlich) zu wild. Die eigentliche Frage war, ob sich ein Blick auf Java lohnt. Meine Antwort: Ja, auf jeden Fall. Je gründlicher und länger, desto besser.
Alles andere, was sich hier auf den letzten 4 Seiten entwickelt hat, ist nur noch schreien im finsteren Wald und teilweise dermassen unqualifiziert und am Thema vorbei, dass man den Thread lieber schliessen sollte.
-
pale dog schrieb:
CStoll schrieb:
@pale dog: Was ich so beobachte, bist du recht gut in C unterwegs. Wie kommt es dann, daß du so gegen C++ stehst (ist doch viel näher an C als Java)?
ja, schon, aber C++ ist trotzdem sehr weit entfernt von C.
die sprache C++ wirkt auf mich ziemlich lieblos zusammengestückelt, so wie ein experimenteller versuch, C aufzumotzen, aber ohne irgendwann weiterzumachen.Ja, was denn nun? "sehr weit entfernt" oder "Versuch, es aufzumotzen"? Und übrigens wird C++ sehr wohl noch weiterentwickelt.
Übrigens ist Java noch weiter von C entfernt - ist das jetzt besser oder schlechter? (und BASIC oder Delphi erst - die sind so weit von C entfernt, daß sie noch nichtmal die selbe Syntax verwenden :D)
...und die user haben ständig haarsträubende probleme damit (siehste ja hier im C++ forum z.b. 'delete' oder 'delete[]'?, muss ich einen copy-constructor schreiben?, hilfe, mein default-zuweisungsoperator geht nicht mehr!)
Willst du etwa behaupten, in Java gibt es keine Probleme? Vielleicht gibt es dort nicht die Schwierigkeiten, die du hier genannt hast, aber bestimmt genug andere.
(apropos: Wie arbeitet eigentlich der Default Copy-Ctor und Zuweisungsoperator in Java? (tiefe Kopie oder flache Kopie?) Und was muß man machen, wenn einem dieses Verhalten nicht gefällt?)C-ähnliche, objektorientierte sprachen wie etwa Objective-C und D scheinen mir da wesentlich durchdachter zu sein...
Von Objective-C weiß ich nur, daß es eine eigene Syntax verwendet, die intern dann in C-Quelltext übersetzt wird, bevor er durch den Compiler gejagt wird (da ist C++ wesentlich homogener). D wäre einen Blick wert, aber da ist es noch zu früh, sein Potential zu erkennen.
-
pale dog schrieb:
ja, hab's überflogen.
es gibt verschiedene typen von objekten und sie haben sogar ein property namens '[[class]] "A string value indicating the kind of this object."'
die objekte werden nur nicht erzeugt wie etwa in Java, recht seltsames zeug, Javascript eben...die Objekte werden eben on-the-fly also während der Benutzung konstruiert. Das finde ich einen ganz netten Ansatz. Macht JavaScript _programmiertechnisch_ imho wesentlich interessanter als den Namensvetter.
[quote="CStoll"]Von Objective-C weiß ich nur, daß es eine eigene Syntax verwendet, die intern dann in C-Quelltext übersetzt wird, bevor er durch den Compiler gejagt wird (da ist C++ wesentlich homogener).[/url]
Objective-C finde ich schon interessant (gibt ja auch Objective-C++!). Was es im Gegensatz zu C++ anders macht ist die dynamische Objektorientierung mit einem MOP. Das erlaubt eben dynamischere Spielereien, wie man es aus Lisp oder Smalltalk kennt.
Aber als wesentlich durchdachter würde ich es jetzt auch nicht bezeichnen. Weiß nicht woran net das fest macht.
-
SammyRukka schrieb:
...Die eigentliche Frage war, ob sich ein Blick auf Java lohnt. Meine Antwort: Ja, auf jeden Fall....
1.) Dem stimme ich vollkommen zu !
2.) Auch der Blick auf C++ lohnt sich auf jeden Fall
3.) Wer immer später mal ernsthaft("professionell") programmieren will, wird versuchen, sich möglichst viel anzusehen und nicht als erstes untersuchen, was er sich denn "...sparen könnte..."Gruß,
Simon2.
OT schrieb:
Die letzten paar Threadseiten waren mir ein wenig zu sehr von "Gemächtvergleich" geprägt, als dass ich mich ernsthaft damit beschäftigen wollte.
(eine Kommunikationsplage, die ich nur aus diesem Forum kenne - vertritt jemand eine andere Meinung, hat er sofort "... ja überhaupt keine Ahnung und sollte zu Zukunft schweigen und alles abnicken, was der Meister von sich gibt ..." )
-
CStoll schrieb:
pale dog schrieb:
CStoll schrieb:
@pale dog: Was ich so beobachte, bist du recht gut in C unterwegs. Wie kommt es dann, daß du so gegen C++ stehst (ist doch viel näher an C als Java)?
ja, schon, aber C++ ist trotzdem sehr weit entfernt von C.
die sprache C++ wirkt auf mich ziemlich lieblos zusammengestückelt, so wie ein experimenteller versuch, C aufzumotzen, aber ohne irgendwann weiterzumachen.Ja, was denn nun? "sehr weit entfernt" oder "Versuch, es aufzumotzen"? Und übrigens wird C++ sehr wohl noch weiterentwickelt.
beides. ein komischer flickenteppich eben. es wurde auch vieles von C übernommen aber ohne 100% abwärtskompatibel zu sein. es gibt nicht umsonst das zitat "C++ is multiparadigm in the same way a dog with 4 table legs nailed onto it is an octopus"
CStoll schrieb:
Übrigens ist Java noch weiter von C entfernt - ist das jetzt besser oder schlechter?
besser. Java versucht gar nicht erst C-kompatibel zu sein. Java hat einen komplett anderen weg eingeschlagen - und der erfolg spricht ja für sich.
...und die user haben ständig haarsträubende probleme damit (siehste ja hier im C++ forum z.b. 'delete' oder 'delete[]'?, muss ich einen copy-constructor schreiben?, hilfe, mein default-zuweisungsoperator geht nicht mehr!)
Willst du etwa behaupten, in Java gibt es keine Probleme? Vielleicht gibt es dort nicht die Schwierigkeiten, die du hier genannt hast, aber bestimmt genug andere.
klar gibt es welche, aber ich behaupte dass benutzer und gerade einsteiger wesentlich weniger schwierigkeiten mit Java haben als mit C++, allein schon deshalb, weil C++ user sich auch noch mit C-macken auseinandersetzen müssen.
(apropos: Wie arbeitet eigentlich der Default Copy-Ctor und Zuweisungsoperator in Java? (tiefe Kopie oder flache Kopie?) Und was muß man machen, wenn einem dieses Verhalten nicht gefällt?)
Java-klassen haben keinen default copy-ctor, man muss sich selber einen schreiben, wenn man sowas braucht. der zuweisungsoperator für objekte kopiert referenzen d.h. es wird kein neues objekt erzeugt oder irgendwelche members dupliziert.