c++ vs. java... was hat zukunft
-
pale dog schrieb:
Simon2 schrieb:
Kann vielleicht auch eher daran liegen, dass hier immer frustrierte Javafans auftauchen, die nicht verkraften, dass ihre Sprache immer noch nicht "den großen Bruder C++ verdrängt hat"
das glaube ich nicht.
so ein verdrängungsprozess läuft in etwa ab wie darwins 'natürliche auslese'
nach dem motto 'das bessere ist des guten feind' werden programmiersprachen mit dem höheren gebrauchswert andere zurückdrängen.
daran können alle flamewar-gestählten Java- und C++ freunde dieser welt nichts ändern...
Darwin sagte nicht dass der besser gewinnt sondern der besser angepasste. Und das dürfte in diesem Zusammenhang nicht unerheblich sein
-
[opinion]
quick 'n dirty, lahm, billig => Java
elegant, fast as hell, teuer => C++
[/opinion]Verdammte Flamewars...
greetz, Swordfish
-
Gast++ schrieb:
Artchi schrieb:
Will ich Java 1.6-Runtime nutzen, muß der User im "schlechtesten" Fall eben die Runtime erstmal installieren. Und? Dann kann ich auch sagen, dann muß der User z.B. halt erstmal gtkmm Version XYZ installieren. Und somit habe ich unter C++ genau die gleichen Verhältnisse.
Dem schliess ich mich an; eine kleine Geschichte dazu:
Unlängst wollte ich mir einen kleinen Client für einen XML-RPC Server bauen.
=> Perl : v.h.
=> Python : v.h.
=> C++ : Google / Download / Compile / Install / Link / Run=> Java : SUN warf mir ein komplettes Webservice SDK entgegen; ca 500 MB + 500 MB für das Server-Environment. Jetzt erzeugt nach jedem Reboot irgendein Java-Update-Tool eine Exception.
Mag sein dass ich etwas falsch gemacht habe; ich hab nach "Java XML RPC" googled; bin bei SUN im Enterprise SDK gelandet und hab imo den ersten passenden Download genutzt.
=>
Müsste jetzt also ein Client > 500 MB Zusatzsoftware mitinstallieren? Von der Implementierung des Clients in Java habe ich Abstand genommen; für solchen Overhead habe ich einfach keine Zeit.
Grüsse
*this
sorry kann ich nich nachvollziehen, bei meinem google liefert "java xml rpc" als erstes suchergebnis die apache xmlrpc library und ansonsten hauptsächlich javadoc seiten - und keine sun j2ee seite...
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
google ich stattdessen nach "jdk download" komme ich auch auf die richtige webseite
um mir mein jdk runterzuladen (56 mb). und wenn ich mir dann noch immer arbeit ersparen will kann ich mir ja auch noch was google bei "java xml rpc" als erstes ergebnis ausspuckt runterladen, apache xmlrpc (oder ich benutze eine andere api) 
-
Artchi schrieb:
Also eine Java Runtime zu installieren ist nicht schlimm. Vorausgesetzt der User hat die Möglichkeit dazu (Adminrechte).
Bei deinem RPC-Server scheint es wohl eher ein Bug/Inkompatibilität zu sein... wie es ihn in jedem anderen Programm in jeder Sprache geben kann. Aber 500 MB für einen Server ist normal. Ist bei unseren IBM-Webspheres auch nicht anders. Mit dem SDK kommen wir auf 3 CDs.
Aber ist das nicht Offtopic??? Deshalb kein weiterer Beitrag dazu von mir.
Topic ist hier doch der Vergleich von C++ und Java.
Offtopic ist nur Deine etwas oberflächliche Systemberatung. Die war auch gar nicht erbeten; trotzdem Danke für Deine Bemühungen!
Grüsse
*this
-
kann besser googlen als d schrieb:
sorry kann ich nich nachvollziehen,
Richtig. Du kannst es nicht nachvollziehen. Passiert öfter, gell?
kann besser googlen als d schrieb:
bei meinem google liefert "java xml rpc" als erstes suchergebnis die apache xmlrpc library und ansonsten hauptsächlich javadoc seiten - und keine sun j2ee seite...
Was nützen mir apache-Links wenn ich ein Java-Paket brauche?
Wer lesen kann ist klar im Vorteil; wer darüber hinaus noch mitdenkt umso mehr...
Grüsse
*this
-
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 link' schrieb:
Apache XML-RPC is a Java implementation of XML-RPC,
wer darüber hinaus noch mitdenkt umso mehr...
anscheinend hast du ja sehr viel mitgedacht, als du dir für einen xmlrpc client einen j2ee application server runtergeladen hast...
Grüsse
*this
grüsse,
der gleiche von oben mit anderem nick
-
[quote="lol geil"]
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?
Hast Du mal die Installationsroutinen von SUN, die Dich ständig auf einen fehlenden Server hinweisen, getestet bevor Dich hier zu Wort gemeldet hast ?=> Schwafel mich bitte nicht voll mit Deinem Halbwissen!
Grüsse
*this
-
Gast++ schrieb:
Bist Du sicher das Du weisst was der Apache eigentlich ist?
Der unreg meint eine Lib von der Apache Software Foundation, kein Modul für deren HTTP Server...
-
finix schrieb:
Gast++ schrieb:
Bist Du sicher das Du weisst was der Apache eigentlich ist?
Der unreg meint eine Lib von der Apache Software Foundation, kein Modul für deren HTTP Server...
...und bei weiteren unklarheiten: http://www-128.ibm.com/developerworks/xml/library/j-xmlrpc.html
http://www.xmlrpc.com/directory/1568/implementations
-
[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
