[QUOTE=kappesf]Immer diese Diskussionen… Wir suchen zur Zeit black walnut Carpenter![/QUOTE]Viel Spaß… Ich kann leider nur Mahagoni blau und Fichte schweinchenrosa. Zimmermann bleibt Zimmermann. 
Aber ob ein Programmierer immer ein Programmierer bleibt, wage ich mal zu bezweifeln.
[QUOTE=Spacerat]Viel Spaß… Ich kann leider nur Mahagoni blau und Fichte schweinchenrosa. Zimmermann bleibt Zimmermann. Aber ob ein Programmierer immer ein Programmierer bleibt, wage ich mal zu bezweifeln.
Der link is hammer 
[QUOTE=Akeshihiro]Der link is hammer :D[/QUOTE]Dann ab damit in die Witzecke…
Dein Link, als kannst du es ja machen 
Aso, und um mal auf das zurück zu kommen:
[QUOTE=Spacerat;28224]Ahh, ein Konvertit :lol:. Die können wohl am besten beurteilen, warum sie nun Java als Primärsprache nutzen und zwar ohne das sie sich auch einen „Glaubenskrieg“ einlassen müssen. Darf man fragen, warum du nun Java favorisierst? Ich frage nur interessehalber, evtl. stimmen deine Gedanken ja mit meinen überein.
Ich frage mich seit geraumer Zeit schon, ob es überhaupt noch zeitgemäß ist, Sprache und Zielplattform immer in einen Topf zu werfen. Wenn es entsprechende Kompiler gäbe, könnte man nämlich, wenn mans genau nimmt jede Sprache auf ein beliebiges System portieren, auch wenn man nicht viel Nutzen daraus ziehen kann. Programmiersprachen sind nun mal portabel, im Gegensatz zu den Produkten der jeweiligen Kompiler und genau da liegt der Ansatz von virtuellen Maschinen bzw. Prozessoren. Ist zumindest schon mal ein gravierender Unterschied, ob für die Verwendung einer Software nur noch eine Runtime-Lib oder virtuelle Maschine erforderich ist, statt ein komplett anderes Beriebssystem.[/QUOTE]
Wie siehst du das denn? Oder hast du das schon beantwortet und ich bin einfach blind 
[QUOTE=Akeshihiro]Wie siehst du das denn? Oder hast du das schon beantwortet und ich bin einfach blind :D[/QUOTE]Also alles in allem steht’s schon da. Nativen Code (z.B. JNI) braucht man nur noch selber schreiben, wenns absolut notwendig ist, was immer seltener der Fall ist. Sogar Windows setzt schon intern verstärkt auf seine VM (dotNet, Windows läuft schon längst nicht mehr ganz ohne), anscheinend, weil die Handhabung von Bytecode bzw. die Bytecode-Sprachen (C#, Java) viel einfacher sind, als z.B. Ass/C/C++, ganz einfach deswegen, weil Dinge wie Speicherorganisation und GC in diesen weiträumig (und inzwischen auch recht gut funktionierend) automatisiert wurden. Warum also, sollte man sich noch das Leben schwer machen, indem man sich noch mit Fragen wie Call-by-Value oder Call-by-Reference, Pointer oder Referenz usw. rumschlägt? Da arbeiten doch schon genug erfahrene Entwickler dran, indem sie Virtuelle Maschinen (dotNet, JVM, irgendwelche Game- und/oder Script-Engines) entwickeln oder optimieren.
[QUOTE=Spacerat][…]. Sogar Windows setzt schon intern verstärkt auf seine VM (dotNet, Windows läuft schon längst nicht mehr ganz ohne)[…]
[…] die Bytecode-Sprachen (C#, Java) viel einfacher sind, als z.B. Ass/C/C++, ganz einfach deswegen, weil Dinge wie Speicherorganisation und GC in diesen weiträumig (und inzwischen auch recht gut funktionierend) automatisiert wurden.[/QUOTE]
Wo ist das denn her? Blöken nicht immernoch einige C# Devs, weil sie nicht wissen welche Richtung MS einschlagen wird? Auch aufgrund der Tatsache das MS C++ wieder stärker unterstützt und sich in diese Richtung bewegt?
Davon abgesehen, bin ich hier der Einzige welcher der Meinung ist C++ hat sich erheblich weiterentwickelt und das die Sache mit der Speicherverwaltung gar nicht mehr so schlimm ist und ziemlich überbewertet wird?
Nichtsdestotrotz verwende ich kein C++ (mehr) aufgrund der einfachen Tatsache das ich auf der Arbeit und privat eher an Desktopanwendungen bastle die keine Geschwindigkeitsrekorde verzeichnen müssen und man natürlich das unglaublich große Ökosystem um Java nutzen kann. Daher liegt mein Fokus derzeit mehr auf z.B. Scala.
Zum Topic, mir fallen noch ein.
Runescape
Mucommander
PS: Die mangelnde Javapräsenz auf Anwenderdesktops hat wohl auch historische Gründe wie
[ul]
[li]Mangelnde Geschwindigkeit in der Anfangsphase.
[/li][li]Ständige Schwachstellen bei Applets und der daraus folgenden Suggestion Java sei per se unsicher
[/li][li]Besetzung der meisten Anwendungsprogramme durch Software die einfach schon vorher da war.
[/li][li]Viel größerer Wissenspool bzgl. Spieleentwicklung im Bereich systemnaher Programmiersprachen.
[/li][li] etc.
[/li][/ul]
[QUOTE=ThreadPool]Wo ist das denn her? Blöken nicht immernoch einige C# Devs, weil sie nicht wissen welche Richtung MS einschlagen wird? Auch aufgrund der Tatsache das MS C++ wieder stärker unterstützt und sich in diese Richtung bewegt?[/QUOTE]Wie kann denn ein OS eine Programmiersprache stärker unterstützen als eine andere? Etwa durch diverse APIs oder ähnliches? MS selber programmiert Anwendungen auf beiden Schienen. Auf jeden Fall löst dotNet ja nicht C++ ab, sondern mehr oder weniger COM, OLE und ActiveX (afaik jedenfalls). Ausserdem ists ja auch so, dass man theoretisch für jede Laufzeitumgebung beliebige Compiler basteln kann, also z.B. auch solche, die aus C+±Quelltext JVM-Bytecode machen. Nur tut das keiner, weils relativ nutzlos wäre.
[QUOTE=ThreadPool]Wo ist das denn her? Blöken nicht immernoch einige C# Devs, weil sie nicht wissen welche Richtung MS einschlagen wird? Auch aufgrund der Tatsache das MS C++ wieder stärker unterstützt und sich in diese Richtung bewegt?
Davon abgesehen, bin ich hier der Einzige welcher der Meinung ist C++ hat sich erheblich weiterentwickelt und das die Sache mit der Speicherverwaltung gar nicht mehr so schlimm ist und ziemlich überbewertet wird?
Nichtsdestotrotz verwende ich kein C++ (mehr) aufgrund der einfachen Tatsache das ich auf der Arbeit und privat eher an Desktopanwendungen bastle die keine Geschwindigkeitsrekorde verzeichnen müssen und man natürlich das unglaublich große Ökosystem um Java nutzen kann. Daher liegt mein Fokus derzeit mehr auf z.B. Scala.
Zum Topic, mir fallen noch ein.
Runescape
Mucommander
PS: Die mangelnde Javapräsenz auf Anwenderdesktops hat wohl auch historische Gründe wie
[ul]
[li]Mangelnde Geschwindigkeit in der Anfangsphase.
[/li][li]Ständige Schwachstellen bei Applets und der daraus folgenden Suggestion Java sei per se unsicher
[/li][li]Besetzung der meisten Anwendungsprogramme durch Software die einfach schon vorher da war.
[/li][li]Viel größerer Wissenspool bzgl. Spieleentwicklung im Bereich systemnaher Programmiersprachen.
[/li][li] etc.
[/li][/ul][/QUOTE]
Entwickelt hat sich C++ schon sehr stark und ich glaube das hat auch niemand bestritten. Es ist eher so, dass es niemand angesprochen hat. Wenn man die Kniffe kennt, wie man Speichermanagement umgehen kann, dass ist das auch kein so gewaltiges Argument mehr, das stimmt. Aber wie du schon selbst sagtest, das Ökosystem aus der Java-Welt ist deutlich bequemer als die Vorzüge einer Sprache wie C++, insofern …
Doch doch, C++/CLI ist C++ für .NET, also das gibts schon. Nur nutzt das kein C+±Programmierer, der sein Gesicht wahren will. Da sind dann C# und VB.NET eher Kandidaten für die Programmierung mit .NET.
Also ich finde für Kleine Programme ist java echt gut aber sobald man an Datenverarbeitung CRM etc. kommt ist Java eher ein Langwirige sache und sollte auf C# und VB zurückgreifen. Alleine Das Kopieren von Verzeichnissen mit mehreren ebenen und mehreren Datein ist recht Kompliziert. bei VB
My.Computer.FileSystem.CopyDirectory(Quelle, Ziel)
ps. der VB BB Code Fehlt
[QUOTE=Andy16823]Also ich finde für Kleine Programme ist java echt gut aber sobald man an Datenverarbeitung CRM etc. kommt ist Java eher ein Langwirige sache und sollte auf C# und VB zurückgreifen. Alleine Das Kopieren von Verzeichnissen mit mehreren ebenen und mehreren Datein ist recht Kompliziert. bei VB
My.Computer.FileSystem.CopyDirectory(Quelle, Ziel)
ps. der VB BB Code Fehlt[/QUOTE]Unterschätz’ da mal Java nicht. Solche Methoden sind sehr schnell implementiert. Allerdings hat man in der standard API evtl. nur drauf verzichtet, weil schon beim Kopieren einzelner Dateien Exceptions fliegen können (z.B. Access- und/oder IOExceptions). Wenn man sich eine solche “copyDir()”-Methode also selbst implementieren muss, kann dabei auftretende Fehler individuell behandeln anstatt das der Vorgang ohne Rollbackmöglichkeit gänzlich abgebrochen wird.
Gerade wenn die Logik komplexer wird, dann spielt Java seine Stärken aus.
Du meintest mit CRM doch Customer-Relationship-Management, oder? Hast du diesbezüglich bereits Erfahrungen?
Für Dateiverschiebegeschichten sind andere Sprachen sicherlich besser geeignet als Java. Das .NET-Framework ist von Natur aus auch viel Betriebssystemnäher als Java - es ist schließlich von einem Betriebssystemhersteller für genau dieses Betriebssystem entwickelt worden. Die Windows-API Funktionen sind daher alle (?) im Framework integriert.
[QUOTE=Andy16823]Also ich finde für Kleine Programme ist java echt gut aber sobald man an Datenverarbeitung CRM etc. kommt ist Java eher ein Langwirige sache und sollte auf C# und VB zurückgreifen. Alleine Das Kopieren von Verzeichnissen mit mehreren ebenen und mehreren Datein ist recht Kompliziert. bei VB
My.Computer.FileSystem.CopyDirectory(Quelle, Ziel)
ps. der VB BB Code Fehlt[/QUOTE]
Wie kommst du auf diese Aussage ueber Java?
Java mit commons-io FileUtils
new File("/destination"));```wow, das sich aus einer einfachen frage sowas entwickelt, respekt
um vielleicht mal aus meinen täglichen erfahrungen zu plaudern : man kann mit java nahezu alles machen (lassen wir mal das ganze OS- und HW-spezifische gedöns via JNI weg)
man muss es nur können
wir haben bei uns auch eine in java geschrieben software, die auch an sich das macht was man von ihr verlangt
allerdings kann man an dieser software den wissensstand der entwickler sehr gut ablesen
ich will jetzt niemanden persönlich angreifen, aber es betrifft anfänger-fehler wie “I/O-ops im EDT” oder “catch(NPE) statt if(null)”, und das von gelernten und vermutlich teilweise studierten software-entwicklern
sicher, einmal das ding komplett refactoren und dabei auf gewisse standards achten und alles wäre in ordnung, und wirklich SO aufwändig würde ich das ganze nicht betrachten : ne gute IDE die gewisse java-pattern automatisch “korrigiert” und ein großteil kann automatisch ablaufen
ich hab mich selbst zwar noch nie an einer so umfangreichen anwendung versucht, aber ein JFrame mit nem JTabbedPane und mehrere JPanel als tabs, mit nem GUI-builder kein problem, auch wenn der code ziemlich ugly wird, und dazu ein paar dialoge, das ganze noch sauber als MVC mit RMI
ganz erlich, so schwer dürfte es nicht sein, und wirklich viel code dürfte da auch nicht entstehen
ABER : wäre das ein grund dafür eher DotNET oder gleich C/++ zu nutzen ? NEIN ! es ist völlig egal welche sprache man nutzt, wenn man fehler macht dann macht man sie eben, gleich ob Java oder C
um vielleicht noch mal auf die eigentlich frage zu kommen : es gibt sehr viel software die in java geschrieben ist, und dank android erlebt java mal wieder n positiven side-kick
aber grundsätzlich könnte man sehr viel was sonst in DotNET oder anderen sprachen erstellt wurde auch in java umsetzen, was gerade office-software angeht wenn man sich z.b. mal OpenOffice oder SAP ansieht
und wenns um “spiele” geht : siehe Minecraft oder Jake2
Umgekehrt kann man sauberen Code auch in fast allen Sprachen schreiben, die meisten Pattern sind nur OOP-Spezifisch, da ist es egal ob man Java oder C# benutzt.
Bei clean Code geht es sogar noch weiter, guten Code kann man in fast allen Sprachen schreiben die es erlauben Elemente zu benennen (hässlichen genauso).
Gruß
[QUOTE=maki]Wie kommst du auf diese Aussage ueber Java?
Java mit commons-io FileUtils
new File("/destination"));```[/QUOTE]
die ist aber nicht in der API bei oder, weil ich find die nicht ?wie seht das damit aus mit weitergabe etc. ?
Ich hab nichts dagegen, wenn jemand eine Rechtschreibschwäche, darüber lies ich einfach hinweg. Aber es ist echt nervig, wenn sich jemand füttern lassen will. Gewisse Informationen darf man sich dann schon selber suchen.
[QUOTE=TheDarkRose]Gewisse Informationen darf man sich dann schon selber suchen.[/QUOTE]Bei 'ner echten Rechtrscheibschwäche (ganz Krass: Legasthenie) führen diese Suchen aber oftmals zu nichts, weil nicht jeder Rechtschreibfehler berücksichtigt werden kann.