C/C++ wieder im kommen?
-
Lichtweite schrieb:
Java ist einer der Sprachen für die neue Computer-Ära der Mobiledevices, warum sollte gerade die langsam aussterben? Das macht überhaupt keinen Sinn. Baut SAP nicht auch auf Java und diverse Großwebprojekte wie eBay?
Da ich vorrangig die Theorie vertrete, dass Java eine sterbende Sprache ist: Mobile-Devices sind aktuell iOS (ObjectiveC), Windows 8 wird vermutlich nicht aufzuhalten sein (was vermutlich alles frisst was sich durch Visual Studio ziehen lässt - also kein Java) und natürlich Android (die eine VM haben, die über, aber nicht mit Java gefüttert wird). Java ist der Teil, der am leichtesten auszutauschen ist, weil er nur Zulieferer ist. Liefern können auch andere.
Die neue Computer-Ära ist jetzt etwa 5 Jahre alt. Für eine "Ära" vielleicht etwas kurz. Alleine die Tatsache, dass vor 5 Jahren keiner Smartphones hatte, zeigt wie schnell sich in dem Bereich alles ändern kann. Davor war es noch die Symbian-Ära... Kennt noch wer Palm?
Android ist dabei das beliebteste, aber irgendwo auch nur eine Kompromisslösung. Windows 8 hat die Chance einfach so zu verschwinden, wie auch ein großer Erfolg zu werden. Ich schätze, dass Android am ehesten die Chance hat, sich selbst in Konkurrenz aufzuspalten, denn die Update-Fähigkeit ist hier ja eher bescheiden. Amazon bietet bereits einen Fork an - und wenn man ehrlich ist, bedeutet jedes Händi-Modell quasi einen eigenen Fork. Da wird sich was ändern müssen, oder es fällt früher oder später aus der Rechnung raus.Dass Java eine Luftnummer ist, sagte ich bereits während des Hypes, also so um die 2001. Und zwar während man mir Java beibrachte. Aber SAP arbeitet damit, hört man immer noch. Vor zwei oder drei Jahren fragte ich einen befreundeten SAP-Programmierer zu Java bei SAP. Er grinste und meinte, dass wichtige Javaprojekte neu implementiert werden und Kleinst-Projekte in Java nur noch von Leuten angefangen werden, die frisch bei SAP und noch nicht geimpft sind.
Klingt für mich nach einer großen Vergangenheit, nicht nach einer großen Zukunft.Lichtweite schrieb:
C++ bleibt für mich die Königssprache, aber sie ist wohl vielen Programmierern einfach zu schwer und warum sollte sie die sehr flache Lernkurve auch in Kauf nehmen, wenn sie mit einen anderen Werkzeug viel entspannter und kostengünstiger zum Ziel kommen?
Erfahrungsgemäß hat die Lernkurve in C# und besonders in Java quasi einen Absacker, wenn man aus dem gewohnten Environment raus muss, um Dinge zu erledigen, die man in C# oder Java nicht kann. Dann muss man umdenken - meistens zu C/C++ und kann erstmal gar nix. Java-Programmierer sehen mit JNI überhaupt nicht entspannt aus und auch für C++-Entwickler sieht das nicht schön aus.
Wir machen das ganze mit C#, bzw. .NET, da werden komplette Datenstrukturen zwischen .NET und nativem Code hin und hergeschoben. Der selbstgeschriebene Codegenerator dafür funktioniert inzwischen wahrscheinlich zuverlässig.
Die C#-Entwickler werden diesen aber nicht reparieren, falls der Autor mal ausfällt. Ist der Autor in Urlaub, dann bin ich das hoffentlich auch. ^^Es gibt da nämlich auch eine Kurve, die die Herausforderung beschreibt. Diese ist bei C++ am Anfang vergleichsweise steil, sie flacht auch nie wirklich ab, aber so lernt man auch, dass man auch größere Herausforderung leisten kann. Ich mache Compilerbau, 3D-Konstruktion und -Visualisierung, Web- und Netzwerkprogrammierung und Datenbanken - alles in C++. Flache Lernkurven wären Fließbandarbeit - dafür braucht man Java/C# ja letztendlich auch. In Java und C# sind ist die Herausforderung am Anfang flacher, entspannter und vor allem - darum geht es schließlich - kostengünstiger. Eine kostengünstigere Ausbildung bedeutet auch ein kostengünstigeres Gehalt für den Arbeitgeber.
Dann kommt aber der Moment, wo das Projekt die Größe erreicht, wo es beginnt unüberschaubar zu werden, einem Exceptions aus ganz anderen Teilen des Programms um die Ohren fliegen, die man hier eigentlich gar nicht erwartet hat. Und plötzlich steht eine oder zwei Woche Debugging in der Tür für ein Problem, das kaum einer begreifen kann, geschweige den reproduzieren kann. Gleichzeitig kommt das Feature, das eigentlich entwickelt werden soll, nicht weiter und ein anderes Team, das auf das Feature wartet läuft aus der Planung. Das Meeting, in dem das ganze mit allen besprochen wird, ist nun der kleinste Kostenfaktor.
Wie reproduziert man überhaupt das Szenario, damit man es überhaupt debuggen kann, wenn die Exception nur alle paar Stunden mal fliegt?
Im Idealfall kommt es zu einem Exception-Ping-Pong: Die Exception, die mir um die Ohren fliegt, kommt aus einem Teil des Programms, das gar keinen Fehler enthält. Die Exception fliegt nur, weil denen halt eine andere Exception um die Ohren fliegt und wo kommt die jetzt wieder her?
Alles schon live gesehen... ist lustig, vor allem kurz vor Deadlines.
Auf einmal wird ein abstürzendes Programm zu einer echt coolen Sache: den das Programm hält da an, wo der Fehler auffällt. Das hätte die Sache deutlich vereinfacht.Das ganze hat schon länger nichts mehr mit entspannt oder kostengünstig zu tun. Die Herausforderung, die zu Beginn so entspannt und flach war, ist auf einmal ein Steilanstieg mit Überhang ohne Sicherungsseil, denn die Kosten laufen ja stündlich weiter, inkl. für die Entwickler, die jetzt mit irgendwas anderem beschäftigt werden müssen und den Projektleiter, der sich erstmal was aus den Fingern saugen muss, weil sich seine Planung gerade auflöst.
Das alles ist mit etwas Kenntnis der Sprachen absehbar, es ist im Javadesign regelrecht festgeschrieben, sofern man sich in einem Hype nicht dem allgemeinen Optimismus hingibt, dass jetzt alles möglich ist und alles viel einfacher und vor allem k o s t e n g ü n s t i g e r. ^^
Wer glaubt, dass Java eine Folge von Weiterentwicklung in der Informatik ist, der sollte mal einen BWL-Kurs machen und dort lernen, welche Buzzwords man wo braucht.
C++98 hat auch keine Zukunft, mit C++11 und der Aussicht auf C++14 wird die Sache hier wieder interessanter. ^^
Nicht weil C++14 hammergeile Features haben würde, sondern einfach nur, weil die Sprache nach 11 Jahren Winterschlaf auf einmal in Bewegung kommt.Lichtweite schrieb:
Mal schauen wer in 10 Jahren Recht behält^^
Dann interessiert es eh keinen mehr, was heute geschrieben wurde
-
Die Geschichte mit den Exceptions ist ja mal echt geil und dass ein Programm, das einfach mal abstürzt, da eher ein Fortschritt darstellt steigert es nochmal.
Ich dachte immer, die meisten Android-Apps werden in Java programmiert? Wie das nun Intern funktioniert, da habe ich keine Ahnung?
Du magst ja in vielem Recht habe, aber letztendlich kann man nicht in die Zukunft schauen. Ich bleibe dabei und lerne weiter C++ in der Hoffnung, ich habe lange was von. Das mache ich aber nur noch aus Fun, beruflich möchte ich nix mehr mit IT zu tun haben.
-
Lichtweite schrieb:
Ich dachte immer, die meisten Android-Apps werden in Java programmiert?
Ja werden sie auch und anschließend für die Dalvik VM compiliert.
-
Lichtweite schrieb:
Die Geschichte mit den Exceptions ist ja mal echt geil und dass ein Programm, das einfach mal abstürzt, da eher ein Fortschritt darstellt steigert es nochmal.
In den besten Java-Hype-Zeiten gab es native Programme "Diese Anwendung musste beendet werden - [Ok]". Das meldet das OS und das war scheiße.
Und es gab Java-Programme, die selbst erkannten, dass "Eine nicht behandelte Exception ist aufgetreten. Wenn sie das Programm beenden, sind alle Daten verloren. Drücken Sie Ok um das Programm zu beenden. [Ok]".
Mich hat das eher aufgeregt, dass ich gesagt bekomme, dass meine Daten noch da sind und ich soll das jetzt mit O.K. bestätigen, sie zu killen.... das ist nicht "Ok" und ich bin da definitiv nicht "Ohne Kommentar", denn wenn man schon Exceptions gefangen hat, dann könnte man an der Stelle auf einen solch blöden Hinweis verzichten mit dem ich meine Daten selbst zerstöre darf.Lichtweite schrieb:
Ich dachte immer, die meisten Android-Apps werden in Java programmiert? Wie das nun Intern funktioniert, da habe ich keine Ahnung?
Man programmiert in Java, erhält .class'es für die JVM und konvertiert sie für die Android-VM. .class-Files könnte man auch ohne Java erzeugen.
Lichtweite schrieb:
Du magst ja in vielem Recht habe, aber letztendlich kann man nicht in die Zukunft schauen. Ich bleibe dabei und lerne weiter C++ in der Hoffnung, ich habe lange was von. Das mache ich aber nur noch aus Fun, beruflich möchte ich nix mehr mit IT zu tun haben.
Man stelle sich das Gebiet der Informatik wie eine Stadt vor. In Deinem Haus hast Du Wasser und Strom und alles ist sauber: Hallo Java. Aber wenn das Klo verstopft ist, bist Du aufgeschmissen und es wird mit JNI dreckig. Mit .NET hast Du schonmal Nachbarschaft. Mit PHP stapfst Du mit Gummistiefeln im Garten durch die Blumenbeete. Weder darfst Du ins saubere Haus, noch kommst Du über den Gartenzaun.
Und dann gibt's da noch die Lonerider. Die haben die Straßen gebaut, das Haus, den Garten. Und sie haben das Werkzeug dabei, aus der Wüste drumherum etwas aufzubauen. Das sind die maschinennahen Sprachen, wie Fortran, C/C++, Pascal.Wenn Du also mal raus in die freie Natur willst, da wo am Abgrund kein Sicherheitsgitter steht und ein Stream auch mal Stromschnellen hat, dann solltest Du wissen, was Du da tust. Und da bist Du mit C++ gut beraten. Wenn Du gut in C++ bist, dann baust Du Dir halt Dein Domizil außerhalb der Stadt. Etwas abgelegen, fließend Wasser und Strom musst Du Dir selbst bauen, aber es ist genauso so, wie Du es Dir vorstellst und brauchst.
Viel Arbeit am Anfang. Aber man weiß genau, was wie funktioniert.
-
Oh Gott, soviel Text. Das ist entweder Politik oder Religion. Beides ist kacke!
-
Gibt es auch eine kritische Einschätzung? Das klingt alles so positiv...
-
Jede Sprache wird wohl mal ihr Ende finden, über den Zeitpunkt kann man trefflich streiten.
Wer allerdings nur die Sprachen betrachtet, hat den Schuss nicht gehört.
Es geht hier mittlerweile nur noch um Infrastrukturen, um Umgebungen, und gerade dort sind Sprachen wie Java extrem stark.
Z.B. JBoss Application Server (J2EE) in Verbindung mit Eclipse RichClients und allem damit verbundenen Brimborium ist keine "Sprache".
Es spielt keine Rolle, ob ich meine relativ kleinen Implementierungen in Java oder C++ oder irgendwas code, ich programmiere eh nur noch spezifische Teile für eine "Umgebung". Hier ist Java stärker denn je, eben weil diese Umgebungen unglaublich mächtig sind, und allein deshalb wird sich dessen Ende noch lange hinauszögern. Wenn ich mir hier auf der Firma das Java Magazin durchlese, kenne ich vielleicht 2 Prozent der ganzen Kürzel und Technologien.Außerdem stößt mir diese Behauptung auf, C++ sein "schwer" oder "elitär", nur weil die Sprache 100 tolle Wege bietet, sein Programm ins Nirwana zu fegen. Wenn ein Programmierer erstmal 5 Jahre "Overhead" aufbringen muss, um eine Sprache "richtg zu benutzen", ist das garantiert kein Merkmal für Qualität. Es ist uninteressant, dass aus einer ergebnisorierntierten Sicht zu betrachten, denn beim Kosten/Nutzen Aufwand wirst du eh den Kürzeren ziehen. Es ist also nur eine Frage der Anforderungen.
Das C++ auch einfach historisch bedingt für systemnahe Programmierung stark ist, wo eben keine Highlevel Infrastruktur zur Verfügung steht, bedeutet nicht unbedingt, dass die Sprache genial ist, sondern dass die Konkurrenz entweder schlechter war oder einfach zu spät kam. Daher wird sich auch in Zukunft in diesem Bereich nicht viel ändern, weil du nun mal irgendwo anfangen musst. Von einem erneuten C++ Boom zu sprechen halte ich aber für... wagemutig.The right tool for the right job gilt natürlich nach wie vor, nur hat sich der Begriff "Tool" geändert. Und gerade im Bereich Cloud Cpomputing und Parallelisierung werden die Karten gerade neu gemischt.
-
xaoC schrieb:
Es ist uninteressant, dass aus einer ergebnisorierntierten Sicht zu betrachten, denn beim Kosten/Nutzen Aufwand wirst du eh den Kürzeren ziehen.
Richtig, allerdings können Kosten und Nutzen je nach Anwendung völlig verschiedene Dinge bedeuten. Und gerade jetzt befinden wir uns da wohl in einer Zeit des Umbruchs, denn plötzlich ist Effizienz in vielen Bereichen, in denen sie die letzten Jahre eher eine untergeordnete Rolle gespielt hat, wieder ein wesentlichen Faktor. Am einen Ende des Spektrums haben wir da Google, Facebook etc., die nicht ohne Grund auf C++ laufen, denn bei denen spielt Programmieraufwand im Vergleich zu den Energiekosten der Rechenzentren keine Rolle. Am anderen Ende haben wir Mobile Geräte, wo z.B. Akkulaufzeit ein Alleinstellungsmerkmal ist...
xaoC schrieb:
Es ist also nur eine Frage der Anforderungen.
Exakt und gerade da sehen wir eben, dass Bereiche, in denen C++ stark ist, sehr schnell an Wichtigkeit zunehmen. Das heißt nicht, dass Java ausstirbt oder von C++ ersetzt wird; das wird genauso wenig passieren wie der umgekehrte Fall. Aber C++ wird definitiv wieder aus dem Schatten treten, wo es sich die letzten 10 Jahre versteckt hat...
xaoC schrieb:
Von einem erneuten C++ Boom zu sprechen halte ich aber für... wagemutig.
Ich würde eher meinen, dass es langsam aber doch wirklich schwer ist, die Zeichen nicht zu sehen...
xaoC schrieb:
The right tool for the right job gilt natürlich nach wie vor, nur hat sich der Begriff "Tool" geändert. Und gerade im Bereich Cloud Cpomputing und Parallelisierung werden die Karten gerade neu gemischt.
Richtig und C++ ist plötzlich wieder im Deck enthalten...
-
@dot
Ich denke, wir sehen das ziemlich ähnlich. Beide Sprachen sind hier nunmal in Bereichen ihrer jeweiligen Stärken vertreten, C++ tendenziell als systemnahe Implementierung und Java (+ evtl. Andere) eher aus Anwendungsorientierter Sicht.Eigentlich halt nix neues.
Deswegen sehe ich C++ abseits seines Bereiches auch nicht "boomen", C++ hat hier keine neuen Anwendungsbereiche erschlossen, sondern stellt einfach eine logische Low Level Basis auf einer neuen Art von Geräten. Wenn man das als Boom sieht, Boomen andere Sprachen in IHREN Bereichen erst recht.Kannst du mir einen Abriss geben, inwieweit C++ gerade für parallele Zugriffe sinnvoll sein soll? Oder reden wir hier einfach von mangelnden Low Level Alternativen zu C++, welche das besser könnten? Ich bin aus C++ leider so gut wie raus und habe da keinen Überblick, mein letzter Stand ist, dass C++ diesbzgl. eigentlich garnichts bietet, sondern sozusagen um OS spezifische Threads herumwrappt. In diesem Kontext gesehen müsste man den Mangel einer Standard Thread Implmentierung ja sogar eigentlich besonders herausarbeiten. Denn wenn ich 3rd Party Libs mit berücksichtige, befinden wir uns streng genommen nicht mehr in der "Sprache".
-
Eben dies ist mit dem C++11-Standard hinzugekommen.
-
Eisflamme schrieb:
Eben dies ist mit dem C++11-Standard hinzugekommen.
Da wird sich aber in Zukunft noch mehr tun. Herb Sutter schreibt in dem weiter oben zitierten Artikel
...
At minimum, mainstream operating systems and runtimes will need to be aware that some cores are faster than others, and know which parts of an application want to run on which of those cores.
...
In the next decade, a mainstream operating system (on its own, or augmented with an extra runtime like the Java/.NET VM or the ConcRT runtime underpinning PPL) will be capable of managing cores with different instruction sets and running a single application across many of those cores. Programming languages and tools will be extended to let the developer express code that is restricted to use just a subset of a mainstream programming language (e.g., the restrict() qualifiers in C++ AMP;
...
Libraries and runtimes like OpenCL and TBB and PPL will be extended or duplicated to enable writing loops and other algorithms that run on large numbers of local and non-local parallel cores. Today we can write a parallel_for_each call that can run with 1,000x parallelism on a set of local discrete GPUs and ship the right data shards to the right compute cards and the results back; tomorrow we need to be able to write that same call that can run with 1,000,000,000x parallelism on a set of cloud-based GPUs and ship the right data shards to the right nodes and the results back.
...
The next step is for the data itself to be larger than any node’s memory, and (preferably automatically) move the right data subsets to the right nodes of a distributed computation. For example, we need containers like a distributed_array or distributed_table that can be backed by multiple and/or redundant cloud storage, and then make those the target of the same distributed parallel_for_each call. After all, why shouldn’t we write a single parallel_for_each call that efficiently updates a 100 petabyte table?
-
Muss doch nur Mainstrain werden: http://chirrup.org/rootbeer/rootbeer1_paper.pdf XD
Und ob nun die Cloud auch die lokale Rechenpower übernimmt wollen wir mal sehen, zur Zeit glaub ich nicht daran.
-
Ich glaube nicht das Java an sich aussterben wird. Eher wird weniger damit Entwickelt, weil Oracle immer mehr die Java-Entwicklergemeinde gegen sich aufbringt.
Seit ca 2 Jahren arbeite ich mit C# - aber irgendwie werde ich nicht Glücklich damit.
Ich überlege mir seit geraumer Zeit, meine C++ Kenntnisse aufzufrischen und auszuweiten. Auch wenn C++ recht komplex ist, finde ich mich bei C++ irgendwie "Heimisch".
