Diskussion:Julia (Programmiersprache)
Letzter Absatz der Einleitung (vor Inhaltsverzeichnis) ist sprachlich fehlerhaft.[Quelltext bearbeiten]
Der Absatz scheint eine wörtliche Übersetzung aus dem englischen Beitrag zu sein, ist aber zumindest für mich noch unverständlicher formuliert. (nicht signierter Beitrag von Phophermi (Diskussion | Beiträge) 10:11, 5. Okt. 2023 (CEST))
Wofür steht REPL?[Quelltext bearbeiten]
Klar kann ich googeln, aber wenn hier solche Begriffe verwendet werden, sollte IMHO dazu entweder auf den entspr. Artikel verwiesen werden oder falls nicht vorhanden zumindest in Klammern die Abkürzung stehen.--84.175.255.52 10:35, 13. Nov. 2015 (CET)
- Hab den Begriff jetzt mal verlinkt (leider existiert noch kein Artikel) und kurz die Abkürzung aufgelöst. - Hoo man (Diskussion) 17:51, 13. Nov. 2015 (CET)
Siehe
https://www.heise.de/developer/meldung/Programmiersprachen-Julia-0-3-freigegeben-2300357.html (nicht signierter Beitrag von 95.90.228.51 (Diskussion)) 12:49, 15. Aug. 2017 (CEST)
Teils schlecht formulierte Sätze im Abschnitt "Julia in Verwendung mit anderen Sprachen"[Quelltext bearbeiten]
Da ich nicht allzu gut in Deutsch bin würde ich die Korrektur des Abschnitts "Julia in Verwendung mit anderen Sprachen" lieber jemand Anderem überlassen. Was mir aber aufgefallen ist, sind die folgenden Dinge:
- "Für PHP, Perl und andere Sprachen, Polyglot.jl erlaubt [...]" hört sich insgesamt nicht nach gültiger Grammatik an zumal im selben Satz auch ein Zitatende fehlt.
- "Standardmäßig unterstützt Julia U[...], jedoch können eine erweiterte Unicodeunterstützung [...]" hört sich ebenfalls komisch an.
- Und nach dem letzten Satz im Abschnitt "Weitere" fehlt glaub ich ein Punkt.
- Im vierten Absatz von "Zur Verwendung für Statistik- und Datenanalyse" fehlt ein Verb im Satz. Ich nehme an, dass es sich dabei um "verwendet" handelt.
--Rapus95 (Diskussion) 20:06, 10. Feb. 2016 (CET)
Erledigt Ich habe einige Verbesserungen vorgenommen. --BrunosapiJens (Diskussion) 13:34, 26. Mär. 2016 (CET)
Fachbegriffe[Quelltext bearbeiten]
Für bessere Verständlichkeit bitte ich darum, bestimmte Fachbegriffe geeignet zu verlinken oder zusätzlich zu umschreiben.
- grünes Multithreading
- Typpromotion Erledigt
- Eager Evaluation Erledigt
- gepatchte (das Wort klingt nicht schön)
- DSFMT Erledigt
- überladen Erledigt
- Catch-All-Funktionen
- Mark and Sweep Erledigt
- MCJIT
- Backtraces Erledigt
- Name-Mangling
- Staged Functions
- source-to-source Compiler Erledigt
(Reihenfolge wie im Artikel)
Danke! Da du schon öfters am Artikel gearbeitet hast, verlinke ich dich, @Tambora, evtl. kannst du helfen?
Ansonsten fällt auf, dass viele Kommentare genutzt werden. Da wäre es gut, wenn die Informationen - wenn relevant - in den Artikel eingearbeitet würden und die Kommentare gelöscht würden. Das würde den Artikel verbessern und den Quelltext übersichtlicher machen. --BrunosapiJens (Diskussion) 13:34, 26. Mär. 2016 (CET)
- grünes Multithreading: energiesparendes Teilen in mehrere Prozesse zum Gleichmäßigen geringeren Auslasten des Prozessors anstatt der Vollauslastung eines Kernes mit vierfacher Taktung mit höherem Energieverbrauch. Der Energieverbrauch vervierfacht sich mit Verdopplung der Frequenz. Somit kann eine Aufteilung in zum Beispiel 4 Prozesse, den Energiebrauch im Prozessor mit 4 Kernen theoretisch bis auf ein 1/16 reduzieren, inklusive Grundverbrauch wohl auf 1/4 reduzieren. Will man auch doppelte Geschwindigkeit, kann man mit doppelter Frequenz mit 4 Prozessen theoretisch den Verbrauch mit 4 Kernen auf 1/4 reduzieren und praktisch wohl auf die Hälfte. Zu berücksichtigen ist immer, dass gar nicht ausgelastete Ressourcen ähnlich viel Strom verbrauchen wie gering ausgelastete. Damit sind mit grünem Multithreading zwei Dinge möglich: schnellere Ausführung der Aufgabe mit geringerem Energieverbrauch.
- Diese Erklärung hört sich logisch an. Den Begriff "grünes Multithreading" habe Ich aber bei Google nicht gefunden (sondern ausschließlich diesen Wikipedia Artikel). Für "Green Multithreading" finde Ich den ähnlich klingenden Begriff Green_Thread - der aber eine komplett andere Bedeutung hat. Kannst du zu grünem Multithreading Quellen angeben ? MacCopper (Diskussion) 15:07, 20. Jan. 2023 (CET)
"High-Performance-Programmiersprache"[Quelltext bearbeiten]
Könnte man diesen Begriff aus der Einleitung streichen? Es ist nichts anderes als ein Werbeslogan, wer eine Programmiersprache so bezeichnet ist weder ein Programmierer noch ein Informatiker, so könnte man ja C als eine "High Performance"-Programmiersprache bezeichnen oder auch einfach alle nur weil diese in dem ein oder anderen Bereich irgendwelche "Performance"-Vorteile mit sich bringen. Es ist hier nicht angebracht und führt nur dazu dass besonders Programmieranfänger in die Irre geführt werden - Objektivität meine Damen&Herrn.
Als Alternative wäre die Umschreibung, dass Julia eben für HPC-Bereiche eingesetzt wird. (nicht signierter Beitrag von 217.8.53.38 (Diskussion)) 13:13, 29. Jun. 2017 (CEST)
Erledigt – Evtl. sollte in der Einleitung noch erwähnt werden, dass Julia besonders im HPC-Bereich eingesetzt wird, so wie dies in der Version anderer Sprachen (siehe Englisch) ist. (nicht signierter Beitrag von 95.208.250.235 (Diskussion)) 01:52, 2. Jul. 2017 (CEST)
Gute artikel in Heise mit guten Erklärungen[Quelltext bearbeiten]
Siehe
https://www.heise.de/developer/artikel/Funktionsorientiert-und-schnell-Die-Programmiersprache-Julia-3793160.html (nicht signierter Beitrag von 95.90.228.51 (Diskussion)) 12:37, 15. Aug. 2017 (CEST)
"wohingegen andere wissenschaftliche Sprachen wie beispielsweise Matlab, GNU Octave oder R signifikant langsamer sind"[Quelltext bearbeiten]
Eine derartige wertende und unspezifische Behauptung in einem Einleitungsstatement sollte bitte belegt werden. Sie ist auch in der englischsprachigen Version nicht enthalten. --178.115.129.134 19:04, 7. Feb. 2018 (CET)
Nicht nur das, die Aussagen zur Ausführungsgeschwindigkeit sind vollständig unbelegt. Fortrancompiler werden seit 60 Jahren für “number crunching” optimiert, ohne Referenz zu behaupten, dass Julia ähnlich hoch optimiert sei, halt ich Marketing und konnte ich bisher auch nicht feststellen. Kurz darauf fällt ja auch der Satz dass es einen Garbage Collector gibt, ich halte es für sehr fragwürdig dass eine Sprache mit Garbage Collector ähnliche Performance wie C oder Fortran liefern kann. Wenn tatsächlich das absolut übergeordnete Ziel wäre den schnellstmöglichsten Code zu erzeugen (was z.B. bei Fortran der Fall ist) müsste man den Garbage Collector schon aus Philosophie Gründen rauswerfen.--64.141.127.162 23:46, 31. Mai 2021 (CEST)