Verwendet einfach Java
(teamten.com)- Meine Lieblingssprache ist Python. Trotzdem benutze ich überall Java – sogar für einfache Skripte.
- Ein paar Erfahrungen:
- In einem Unternehmen mit Java-Basis wurden Testszenarien in JavaScript geschrieben. Aber Stack-Traces waren schwer nachzuverfolgen, und durch das Schreiben von Bridge-Code zwischen Java und JavaScript entstand unnötiger Aufwand.
- Logs wurden im JSON-Format gespeichert, und ein Kollege baute ein Programm namens
logcat, das diese Logs verarbeitet. Ich war mit dem Programm zufrieden, aber als später ein ähnliches Programm in Java gebaut wurde, zeigte es mehr als die zehnfache Performance. - Dank der umfangreichen Erfahrung und der vielen verfügbaren Ressourcen zu Java war Java beim Erstellen von Webservices schneller als Python. Genau genommen ist das ein Vorteil, der daraus entsteht, dass man eine Sprache konsequent verwendet.
- Die hitzigste Debatte über Java ist seine Verbosität. Aber das ist überhaupt kein Nachteil. Seht euch die beiden folgenden Codes an.
// java
Map<String,User> userIdMap = new HashMap<String,User>();
// python
userIdMap = {}
- In der Praxis ist der Python-Code aber viel eher so geschrieben. (Wenn nicht, wäre er wirklich schwer wartbar.)
# Map from user ID to User object.
userIdMap = {}
- Mit anderen Worten: Eine dynamisch typisierte Sprache zu verwenden bedeutet, für etwas Cooles in 30 Minuten die Produktivität nach 14 Tagen zu opfern.
- Stack Overflow hat mit ASP.NET (im Jahr 2010) mit 5 Servern 60.000.000 Pageviews bewältigt.
- Schauen wir uns ein Beispiel für Unit-Tests an. Unit-Tests zu schreiben und zu warten kostet Zeit. Gerade Sonderfälle, die sich mit Typen einfach prüfen lassen, werden von Unit-Tests in dynamisch typisierten Sprachen oft nicht gut abgefangen (z. B. Parser).
- (Ein weiterer Grund, warum ich Python nicht benutze:) Ein Quick Hack wächst nach und nach zu einem sehr wichtigen Tool heran, aber es bleibt keine Zeit, es neu zu schreiben. Am Ende kämpft man bei jeder Nutzung mit Performance- und Wartungsproblemen.
- Zum Schluss die Gründe, warum ich Java anderen statisch typisierten Sprachen vorziehe
- C/C++ lässt sich schwer auf meine Arbeit anwenden
- C# bietet zu wenig Cross-Plattform-Unterstützung
- Scala ist zu komplex
- Andere Sprachen wie D oder Go sind für meinen Arbeitseinsatz noch zu neu
- Es gibt ein paar Gründe, warum ich diesen Beitrag zu GeekNews gebracht habe:
- Ich fand es bemerkenswert, zum ersten Mal einen Beitrag mit der Aussage „Ich mag Java wirklich!“ zu sehen. (Nur anhand des Titels dachte ich erst, es käme noch eine Wendung ...)
- Ich fand es interessant, dass der Autor seinen ganz eigenen Werkzeugkasten hat, der aus Java-Tools besteht. Irgendwie musste ich an das Bild eines alten Mannes denken, der umständlich uralte Waffen aus seiner Tasche hervorholt.
- Ich persönlich mag JavaScript und Python sehr. Gleichzeitig wirkt es auf den ersten Blick so, als sei bei diesen Sprachen inzwischen ebenfalls „Typen irgendwie einführen“ der Trend (TypeScript für JavaScript,
typing/mypyfür Python). Als ich diesen Beitrag gelesen habe, kam mir daher der Gedanke, ob mein eigener Einsatz statisch typisierter Sprachen – auf eine Weise, die Typen überhaupt nicht strikt erzwingt – nicht ein Stück weit Selbstzufriedenheit ist.
- Der Autor hat Erfahrung mit Java und Python und hat diese beiden Sprachen direkt verglichen, aber man muss das Denken wohl nicht unbedingt so eng darauf beschränken. Was denkt ihr aus einer breiteren Perspektive über statisch und dynamisch typisierte Sprachen?
PS. Lasst uns keine bestimmte Sprache sinnlos herabsetzen :D
58 Kommentare
Das ist vielleicht eine zu persönliche Erfahrung, aber ich finde, dass bei Java eher die JVM als die Sprache selbst das größte Problem ist.
Ich habe auf verschiedenen Versionen der JVM viel zu oft erlebt, dass die Speicherverwaltung nicht richtig funktioniert.
Dann soll man eben auch
pandasundnumpyin Java bauen und benutzen. Wer so etwas behauptet, sollte nicht in deiner Nähe sein.Java nutzt man einfach für Web-Backends und Python für AI. Wenn es um Performance geht, sollte man eben Rust nehmen, ist das nicht etwas, was sowieso alle wissen?
Aber weil der Anteil von AI in Zukunft wohl steigen wird, denkt man dann nicht auch, dass es langsam Zeit ist, Java aufzugeben? Bei uns im Land gibt es eben oft die Denkweise, dass wir nicht ins Hintertreffen geraten dürfen, haha
Wenn KI immer stärker nachgefragt wird und gewöhnliche REST-APIs oder einfache CRUD-Aufgaben ersetzt werden, sodass solche Systeme nicht mehr gebaut werden, könnte man Java vielleicht aufgeben.
Außerdem denke ich nicht, dass man Sprache und Projektziel immer eins zu eins zuordnen kann, weil Projekte nicht immer aus nur einer Sprache bestehen. Häufig ist die Programmierschnittstelle Python, während für leistungsrelevante Teile nativer Code verwendet wird. So werden Projekte bei uns zwar nicht oft aufgebaut, aber trotzdem.
Die Einleitung ist etwas enttäuschend. Wenn Sie zuerst das Datum genannt hätten, an dem der Originaltext verfasst wurde, hätten etwa die Hälfte der Leute hier das wohl einigermaßen nachvollziehen können ...
Ich habe es auch erst durch die Kommentare der anderen bemerkt.
Allerdings habe ich vorschnell angenommen, dass es erst kürzlich geschrieben wurde, und beim Lesen des Inhalts überhaupt nichts Unnatürliches empfunden. Zumindest auf mich wirkt der Text nach wie vor überzeugend.
Davon abgesehen werde ich künftig ab und zu auch auf das Datum achten, haha
Die Diskussion erhitzt sich.
Wenn es Gegenargumente gibt, schreiben Sie bitte nur deren Inhalt.
Kommentare, die gegen die Nutzungsregeln der Website verstoßen, wurden gelöscht.
Außerdem wurden Konten gesperrt, bei denen regelwidriges Verhalten wiederholt aufgetreten ist; bitte beachten Sie dies.
Wir bitten um eine sachliche Diskussion.
Ich vertraue Google (V8) mehr als Oracle (JVM).
Als ich von Python kam und zum ersten Mal Java gesehen habe, fand ich es wirklich extrem weitschweifig. Wenn ich mir heute aber den Code anschaue, der nötig ist, um Python vollständige Type Hints hinzuzufügen, wirkt das auch nicht mehr unbedingt so, haha. Was ich an Java eher schade finde, ist vielmehr die Naming Convention, Methodennamen extrem lang machen zu wollen.
Ich bevorzuge ebenfalls statisch typisierte Sprachen.
Dynamisch typisierte Sprachen haben zwar ihre bequemen Seiten, aber in Produktionsumgebungen wird die Wartung dadurch oft schwieriger.
Außerdem verfolgen dynamisch typisierte Sprachen in ihrer Designphilosophie häufig das Ziel, „einfachen Code zu schreiben“, weshalb vieles auf Sprachebene implizit verwaltet wird. Dadurch gibt es oft weniger Spielraum für Optimierungen.
Letztlich scheint es sinnvoll zu sein, zwischen Implementierungskomfort und Optimierungsspielraum abzuwägen und je nach Entwicklungsumgebung die passende Wahl zu treffen.
Ein zehn Jahre alter Beitrag, wow.
Stimmt schon, haha.
Verlasst Java einfach und mein Leben ist friedlicher geworden.
Dass Java in der Stack-Overflow-Umfrage im Beliebtheitsranking immer weiter fällt, hat schon seine Gründe.
Gerade in Korea ist es wegen dieses verdammten staatlichen Framework-Zwangs auf Spring festgenagelt, sodass es bei der Jobsuche zwar nützlich ist,
aber außerhalb der Legacy-Welt scheint man im Westen für neue Projekte Java inzwischen kaum noch zu wählen.
Es stimmt, dass es dafür gute Gründe gibt, aber ich denke, Sie betrachten diese Gründe etwas anders.
Auch auf der TIOBE-Website wird erwähnt, dass das Ranking der Programmiersprachen nur als Referenz dienen sollte und nicht in direktem Zusammenhang mit Marktanteil oder Popularität steht.
Die Schlussfolgerung ist also: Python liegt mit überwältigendem Anteil auf Platz 1, aber gibt es entsprechende Tools auf dem Markt?
Am häufigsten begegnet man C/C++, .NET sowie Java (Kotlin) und Swift.
Nur weil es viele Fragen und Suchanfragen gibt, heißt das nicht, dass es auch eine viel genutzte Sprache ist.
Python ist eine Sprache, die jeder verwenden kann, auch ohne ein entsprechendes Studium.
Dass sie populär ist, kann man nicht bestreiten, aber im Entwicklungsmarkt sieht die Sache anders aus.
Instagram verwendet Python im Backend.
Es ist zwar etwas unklar, was genau mit „Tools auf dem Markt“ gemeint ist, aber … reichen Tools wie Django, FastAPI, PyTorch, NumPy, Pandas usw. nicht völlig aus …?
Bin wegen des Titels hereingekommen und habe zuerst die Kommentare erwartet, haha. Heutzutage ist die Bandbreite dessen, worauf man sich bei einer Sprache verlässt, größer geworden.
Wenn man es nur auf die Kostenfrage begrenzt, wird Java in der Cloud wegen des Speicherverbrauchs ziemlich teuer. Programme, die in einer statischen Sprache 100 MB oder 200 MB Speicher brauchen, benötigen, wenn sie in Java geschrieben sind, häufig 1 GB oder 2 GB, und Lightweight-Threads sind wegen der Bibliothekskompatibilität oft nicht nutzbar.
Java ist ebenfalls eine statische Sprache, aber … Speicherprobleme betreffen eher den Garbage Collector oder die JVM, und das von Ihnen erwähnte „Programm in einer statischen Sprache, das 100 MB oder 200 MB Speicher benötigt“ dürfte eher auf native Sprachen wie C oder C++ zutreffen.
Tut mir leid wegen der Halluzination. schnief Java ist natürlich auch eine statische Sprache. Wenn man in der Cloud verschiedene Kosten zusammenrechnet, muss man mit etwa 30.000 Won pro 1 GB Speicher rechnen, daher verursachen mit Java entwickelte Services wohl sehr hohe Kosten.
Wenn Ausnahmen existieren, ist es eine dynamisch typisierte Sprache. Unabhängig davon stimme ich dem Argument zu, dass Typsystem und Speicherverbrauch getrennte Themen sind.
Die Bedeutung der von Ihnen genannten Ausnahme wirkt auf mich zu weit gefasst. Könnten Sie das bitte etwas genauer erklären?
Soweit ich weiß, gilt eine Sprache als statisch typisiert, wenn der Typ einer Variable zur Compile-Zeit festgelegt ist und nur explizit geändert werden kann. Eine dynamisch typisierte Sprache hingegen ist eine Sprache, in der der Typ einer Variable zur Laufzeit beliebig festgelegt und auch implizit geändert werden kann.
Wenn man mit Situationen konfrontiert ist, in denen zur Laufzeit ein Downcast durchgeführt wird oder Ähnliches, muss Java zur Laufzeit Typprüfungen vornehmen. Aus diesem Grund ist Java in solchen Fällen dynamisch typisiert, und dabei entstehen dann Ausnahmen.
Wenn es diese Lücke grundsätzlich nicht gäbe, müsste man Ausnahmen nicht als Ausnahmen bezeichnen.
throwwäre dann nur syntaktischer Zucker für ein Muster, bei dem das geworfene Objekt in einer globalen Variablen abgelegt und dann pergotogesprungen wird.Ähnlich wie das, was Sie beschrieben haben, nennt man Sprachen, die Typprüfungen zur Laufzeit durchführen, dynamisch typisiert. Das gilt jedoch für alle Werte, mit denen in einem Programm gearbeitet wird. Da es sich um einen Artikel über Java handelt, nehmen wir Java als Beispiel: Java-Code wird zur Compile-Zeit typgeprüft, und das impliziert einen wichtigen Punkt, nämlich dass der einem bestimmten Wert entsprechenden Variablenwert mit dem Typ der Variablen übereinstimmen muss.
Wenn die Typprüfung zur Laufzeit erfolgt und man deshalb von dynamischer Typisierung spricht, ist dann C auch eine dynamisch typisierte Sprache? Soweit ich weiß, gibt es dort das Konzept des
void-Pointers. Worin genau liegt der Unterschied zwischen beidem?Welcher C-Compiler fügt Typprüfungen in den Code ein und löst explizite Fehler aus, wenn die Typen nicht stimmen? Falls es eine solche Implementierung gibt, nennen Sie bitte nur ein einziges Beispiel.
In C gibt es dabei praktisch keine Typprüfung. Wenn man Gleitkommadaten als Ganzzahlen liest, passiert ja auch nichts, oder? Das ist nicht dynamisch typisiert, sondern einfach nur gefährlich.
Ja, wenn C die Typprüfung zur Laufzeit machen würde, wäre es eine dynamisch typisierte Sprache.
Weil das aber nicht der Fall ist, ist es statisch typisiert.
Ein
void-Pointer ist einfach ein roher Pointer, dessen ursprünglicher Datentyp nicht bekannt ist. Welcher Typ sich an der Adresse befindet, auf die dieser Pointer zeigt, lässt sich nicht feststellen.Ich bin der Überzeugung, dass die vertraute Sprache die beste ist.
Ich stimme zu. Es scheint auch nicht einfach zu sein, sich von der Sprache zu lösen, die im Team oder in der Organisation verwendet wird.
Zu den verschiedenen Gründen, warum Arbeitsinhalte oder Zuweisungen getrennt werden, kommt noch die Sprache hinzu, was bei bestimmten Personen zu einer Überlastung führt und bei Personalwechseln den Arbeitsfortschritt blockiert. Da dies auch die Einstellung beeinflusst, sollte die Auswahl des Tech-Stacks meiner Meinung nach mit Bedacht erfolgen.
Umgekehrt ist es aber ebenfalls ein Problem, wenn man nur aus Gewohnheit an einer Sprache festhält, für die der Recruiting-Pool klein ist oder die nach der Einstellung zusätzliches Lernen erfordert.
Warum soll C# plattformübergreifend unzureichend sein? Heutzutage werden die meisten .NET-Server-Apps ohnehin auf Linux-Servern bereitgestellt.
Python ist von vornherein kein sinnvoller Vergleich, und im Vergleich zu Kotlin und C# wirkt Java meiner Meinung nach tatsächlich ausschweifender und es fehlen viele benötigte Funktionen.
Ach, das ist ein Artikel von vor 10 Jahren. Inzwischen hat sich die Lage stark verändert.
C# ist ebenfalls eine Sprache, die auf einer virtuellen Maschine läuft, daher hätte die Cross-Platform-Unterstützung eigentlich schon viel früher kommen müssen. Soweit ich weiß, ist sie aber erst vor sehr kurzer Zeit erschienen, und deshalb wird sich wohl noch eine Weile die Wahrnehmung halten, dass man es zwar auch auf anderen Betriebssystemen als Windows ausführen kann, aber eben nur in diesem Sinne.
Außerdem ist es in Linux-Umgebungen, die vor allem auf Server ausgerichtet sind und 365 Tage im Jahr laufen, tatsächlich so, dass man .NET eher meidet als andere Sprachen, deren Stabilität auf dem jeweiligen System seit mehr als zehn Jahren ausreichend belegt ist.
Meint man in diesem Sinne nicht vielleicht, dass es an Cross-Platform-Fähigkeit fehlt?
Aber was genau ist eigentlich der Maßstab dafür, dass sich Stabilität bewährt hat? Ich verstehe nicht ganz, ob Sie damit einfach nur die Nutzungsdauer meinen.
Da der Artikel vor 10 Jahren geschrieben wurde, wurde er so formuliert, kurz nachdem
.NET Coregerade erst entstanden war..NET-Anwendungen laufen bereits stabil und problemlos unter Linux und macOS.
Ich habe mich gefragt, ob es nicht so etwas wie eine Sprache mit einer Python-artig knappen Syntax und statischer Typisierung gibt, und bin dabei zufällig auf GDScript gestoßen. Der große Nachteil ist jedoch, dass es sich nur schwer allgemein einsetzen lässt.
Wenn sich Ihnen die Gelegenheit bietet, empfehle ich Ihnen, mit Godot ein kleines Projekt umzusetzen und GDScript einmal auszuprobieren.
Ich habe, nachdem ich mit Kotlin in Berührung gekommen bin, regelrecht eine Java-Aversion entwickelt...
Ich hatte den Eindruck, dass es in Java immer eine bewährte Antwort gibt, sobald man irgendeine Funktionalität braucht.
Benutzen Sie einfach Kotlin.
Ich hatte ihn ohnehin (auch ich als Kotlin-Nutzer) per E-Mail nach seiner Meinung zu Kotlin gefragt, aber er antwortete mir, dass es schwierig sei, dazu etwas aus Erfahrung zu sagen, weil er es nie benutzt habe.
Ich mag statisch typisierte Sprachen. Sie verringern die Notwendigkeit, ständig über alles nachdenken zu müssen, sodass ich die Zeit für andere Dinge nutzen kann.
Java ist wirklich eine Sprache in einer ganz besonderen Position. Das letzte Mal habe ich Java vor ungefähr zehn Jahren beruflich verwendet, aber wenn ich heute ein Programm nicht als Hobby, sondern für die Arbeit entwickeln müsste, stünde es immer noch auf der Liste der Sprachen, die ich als Erstes in Betracht ziehen würde.
Die Hauptsprachen, die ich aktuell bei der Arbeit verwende, sind Ada und C, aber Tools für den persönlichen Gebrauch oder innerhalb des Teams schreibe ich meist in PowerShell. Wenn ich dann beim Schreiben auch nur kurz Zeit verstreichen lasse (schon 5 Minuten ...), frage ich mich plötzlich: „Welchen Typ hatte diese Variable noch mal?“ Deshalb schreibe ich Typen in letzter Zeit unbedingt explizit dazu. (In PowerShell kann man beim Definieren von Variablen einen Typ angeben oder ihn weglassen und sie dynamisch verwenden.)
Ich mag auch C nicht besonders. Typbezogene Fehler, die der Compiler bei Ada herausfiltern würde, erkennt C überhaupt nicht. Ich denke deshalb oft, dass es schön wäre, wenn es eine Sprache mit einer C-ähnlichen Syntax und dem Typsystem von Ada gäbe.
Mit Javascript und Python werde ich nicht warm. Perl oder Shell Script ... darüber möchte ich nicht einmal nachdenken.
Wegen der grundlegenden Philosophie von C, dem Programmierer zu vertrauen, scheint das wohl unvermeidlich zu sein..
Ach ja, und ich mag Java, aber ich hasse Maven.
In den guten alten Zeiten konnte man mit Ant alles machen!
Ich finde es immerhin beruhigend, dass Java modernen Sprachen langsam folgt, etwa durch die Einführung von Records und Pattern Matching.
Java ist zwar gut, weil es viele Referenzen gibt, aber wenn das der einzige Grund ist, frage ich mich, warum es nicht stattdessen C++ sein sollte.
Ich hätte es gut gefunden, wenn es noch etwas mehr über die Vorteile von Java gegeben hätte.
Ich benutze hauptsächlich C++, deshalb habe ich C++ nur als Beispiel herangezogen. Auch ich halte Java für eine gute Sprache, aber worauf ich hinweisen wollte, war, dass es im ursprünglichen Posting zu wenig um die Vorteile von Java ging.
Wenn man schreibt: „Java ist einfach großartig“, dann sollten eigentlich die Vorteile von Java im Mittelpunkt stehen, aber stattdessen scheint die Kritik an anderen Sprachen im Vordergrund zu stehen.
Wie Sie angemerkt haben, halte ich die JVM von Java ebenfalls für ausgesprochen gut.
Ich stimme voll und ganz zu. Der Hinweis, dass wir die Diskussion nicht unbedingt auf Java beschränken sollten, war genau so gemeint. Scheint aber nicht wirklich so angekommen zu sein..
Dass Java und C++ die Vergleichsgruppe sind, lässt die Glaubwürdigkeit irgendwie stark sinken, haha.
Verwendet einfach Java.
Da Java auf der JVM läuft, kann man die lokale Umgebung und die Maschinenumgebung identisch einrichten. Mit C++ wird es ziemlich viel Zeit kosten, für alle Entwickler und Maschinen dieselbe Umgebung herzustellen. Auch die Wartung ist schwierig ...
Der ursprüngliche Autor scheint Java nur deshalb zu verwenden, weil es sich um eine Arbeit handelt, auf die C++ schwer anzuwenden ist. Wenn er sich wahrscheinlich zwischen Python und C++ entscheiden müsste, hätte er dann nicht C++ gewählt?
Korrektur: "Zum Schluss: Gründe, warum nicht andere statisch typisierte Sprachen" -> "Zum Schluss: Gründe, warum Java gegenüber anderen statisch typisierten Sprachen bevorzugt wird"
Da fängt das Brennholz gut Feuer.. klare Empfehlung
Das ist nicht das Feuer, das ich wollte T_T
Warm … irgendwie …