Announcement: there is an English version of this forum on Oder klingt es viel zu gut um wahr zu sein? Die Beschleunigungsvergleiche erscheinen mir krass unrealistisch. Interessant wäre jetzt natürlich noch ein Geschwindigkeitsvergleich mit Pascal, Delphi bzw Freepascal gewesen, aber dann wären die Zahlen wohl nicht so schon groß gewesen hehe ;-) Und wann gibt es die erste Version für AVRs? :-) https://www.youtube.com/watch?v=FHeSnSFRzSs
:
Bearbeitet durch User
Jede Woche wieder wird eine neue, bunt angemalte Sau durchs Dorf der Programmiersprachen getrieben. Um einen seriöseren Link als ausgerechnet ein Youtube-Filmchen ansehen zu können: https://www.modular.com/mojo
Das youtube kann man aber nebenbei hören;-)
Harald K. schrieb: > Jede Woche wieder wird eine neue, bunt angemalte Sau durchs Dorf der > Programmiersprachen getrieben. Und hast du sie dir schon einmal angeschaut, oder willst du nur hier ätzen?
Wenn halt auch nur ein Teil der Angaben stimmen würde, wäre es wohl die Killersprache schlechthin und damit wohl wirklich das Aus für C / C++ Alleine dadurch, das man nur Python lernen braucht, das MS Basic von heute, also eine sehr leichte Programmiersprache und nur mit minimalem Lernaufwand Mojo nutzen könnte das um Lichtgeschwindigkeiten schneller als Python und unfassbar schneller als C / C++ wäre
:
Bearbeitet durch User
MaWin O. schrieb: > Und hast du sie dir schon einmal angeschaut, oder willst du nur hier > ätzen? Natürlich will ich hier nur rumätzen. Was denn sonst? Ich kenne diese Heilversprechen neuer Programmiersprachen nur zu gut, ich bin schon ein paar Jahrzehnte lang im Geschäft. Wohin das alles steuert, ist ein neues Babylon.
So, jetzt habe ich mal in das Video reingeschaut. Sehr schlecht gemacht. Also das Video. Ziemlich grundlagenloses Gelaber. Insgesamt wird Mojo dort nicht viel anders als Cython dargestellt. Dass das Rust ersetzen kann, halte ich gelinde gesagt für vollkommen Bullshit. Eher genau anders herum.
Am schönsten am Video finde ich ja, welches Logo er für Rust gewählt hat ;)
MaWin O. schrieb: > Sehr schlecht gemacht. Also das Video. Ziemlich grundlagenloses Gelaber. Ach, das ist ja mal substantielle Kritik. Oder doch eher grundlagenloses Gelaber deinerseits?
Max M. schrieb: > Und wann gibt es die erste Version für AVRs? :-) Ist in etwa so sinnvoll wie das entwickeln einer Wärmepumpe zur Heizung von Waggons hinter eine Dampflok.
Meine Glaskugel sagt vielleicht. Meine Erfahrung sagt ignorieren. Sogar wenn das was wird, und es gibt genug Beispiele wo der letzte Dreck was geworden ist, kann man es dann lernen wenn man es braucht. So was auf Vorrat lernen ist Verschwendung.
Re D. schrieb: > Ach, das ist ja mal substantielle Kritik. Oder doch eher grundlagenloses > Gelaber deinerseits? Ja dann gucke das Video doch vielleicht einfach mal. Wer es nicht einmal schafft das Rust-Logo korrekt zu ergooglen, dem glaube ich kein Wort, wenn er bei Mojo über den "Borrow-Checker von Rust" spricht. Insgesamt kommen nur Buzzwords in dem Video vor und wenig bis nichts konkretes. Die gezeigten Beispiele sehen einfach wie Cython-Code aus.
MaWin O. schrieb: > Re D. schrieb: >> Ach, das ist ja mal substantielle Kritik. Oder doch eher grundlagenloses >> Gelaber deinerseits? > > Ja dann gucke das Video doch vielleicht einfach mal. > Wer es nicht einmal schafft das Rust-Logo korrekt zu ergooglen, dem > glaube ich kein Wort, wenn er bei Mojo über den "Borrow-Checker von > Rust" spricht. > Insgesamt kommen nur Buzzwords in dem Video vor und wenig bis nichts > konkretes. > Die gezeigten Beispiele sehen einfach wie Cython-Code aus. Hast du eine Aufmerksamkeitsspanne wie eine Fliege oder warum hast du nichts verstanden was er im Video erzählt hat?
Re D. schrieb: > Hast du eine Aufmerksamkeitsspanne wie eine Fliege oder warum hast du > nichts verstanden was er im Video erzählt hat? Was habe ich denn nicht verstanden?
MaWin O. schrieb: > Re D. schrieb: >> Hast du eine Aufmerksamkeitsspanne wie eine Fliege oder warum hast du >> nichts verstanden was er im Video erzählt hat? > > Was habe ich denn nicht verstanden? Offensichtlich das alles, was du Buzzwords nennst.
Kinders, geht es auch sachlicher. Schreibt das doch per PN
:
Bearbeitet durch User
Wer sich die von mir weiter oben verlinkte Webseite angesehen hat, sollte gesehen haben, daß die ach so tolle Geschwindigkeitssteigerung nur durch Ausnutzung von "AI-Hardware" und anderem ergibt: > Utilize the full power of the hardware, including multiple cores, > vector units, and exotic accelerator units > Mojo leverages MLIR, which enables Mojo developers to take > advantage of vectors, threads, and AI hardware units. Damit ist das ganze schon ziemlich spezialisiert, und z.B. für übliche Microcontroller komplett unbedeutend, denn die haben nur selten mehrere Kerne etc. > Why are we getting a 68,000x speedup instead of the advertised > 35,000x speedup? In short, the benchmarking system is different. > During launch, we evaluated on an AWS r7iz.metal-16xl 32-Core Intel > Xeon Gold 6455B, but in this blog we evaluated on a GCP h3-standard-88 > which uses an 88-Core Intel Xeon Platinum 8481C. The reason we do not > use the r7iz.metal-16xl instance is because it is no longer available. (https://www.modular.com/blog/mojo-a-journey-to-68-000x-speedup-over-python-part-3) Das Python, mit dem sie da vergleichen haben, dürfte auf nur einem Kern mit nur einem Thread laufen - und ist halt eine interpretierte Skriptsprache.
MaWin O. schrieb: > Die gezeigten Beispiele sehen einfach wie Cython-Code aus. Oder Jython, oder Pypy, oder... wobei, meine Lieblingsstelle ist jene, wo er über Python spricht und dabei Ruby-Code zeigt. Aber was weiß ich schon, womöglich hat er sich mit Lark oä. einen Ruby-Interpreter gebaut. :-) Ansonsten bin ich mal gespannt: ein Superset von Python, mit dem Executables erzeugt werden können, die ohne CUDA & Co schneller sein sollen? Hm, sogar Pypy unterstützt nur ein Subset, und Numba möchte zum Optimieren gern Typen und Signaturen. Egal, ich bin sehr gespannt darauf, wie das Ganze jenseits von Mandelbot performen wird. Hat sich eigentlich einer mal das Wunderding heruntergeladen und versucht, ob es die vollmundigen Versprechungen erfüllen kann? Ich würde ja, habe angesichts des ganzen Marketinggeschwafels und des Signup-Zwanges aber irgendwie gerade nur so begrenzte Lust...
Es wäre halt Mega reizvoll mit einer Sprache alle Gängige Abdecken zu können, später mal. Selbst wenn es nur fast so schnell wie C auf einem uC ist, wäre es ein Killerkriterium und sich schon jetzt mehr mit Python zu beschäftigen. Das hatte ich mich auch gefragt, ob die das mit kompilierten Python verglichen haben oder interpretiertem Code verglichen haben. Aber wie gesagt, wenn es auch nur fast so schnell wie C ist, ist es für C /++ zumindest im Hobbybereich das Aus Und das es dann sogar noch ZUSÄTZLICH die Mehrkernoption bietet, ist ein nettes Feature
:
Bearbeitet durch User
Harald K. schrieb: > Wer sich die von mir weiter oben verlinkte Webseite angesehen hat, > sollte gesehen haben, daß die ach so tolle Geschwindigkeitssteigerung > nur durch Ausnutzung von "AI-Hardware" und anderem ergibt: Hm, hieß es nicht vorher, daß das Ding ganz ohne sowas auskommen würde? Oder betrifft das nur explizit die CUDA-Libraries? > Das Python, mit dem sie da vergleichen haben, dürfte auf nur einem Kern > mit nur einem Thread laufen - und ist halt eine interpretierte > Skriptsprache. Eine interpretierte Skriptsprache, die obendrein wie so manche anderen Skriptsprachen einen Global Interpreter Lock (GIL) hat. Und ja, deren 68.000-fache Beschleunigung läuft auf einem fetten Xeon mit 88 Cores, während die Python-Implementierungen nur auf einem Core laufen. Sorry, irgendwie macht das auf mich nur einen begrenzt seriösen Eindruck. Und nachdem ich ein paar Jahre Erfahrung mit Performanceoptimierungen und Benchmarks habe, fehlen mir da auch etliche Angaben zum Benchmark...
Ein T. schrieb: > Eine interpretierte Skriptsprache, die obendrein wie so manche anderen > Skriptsprachen einen Global Interpreter Lock (GIL) hat. Und ja, deren > 68.000-fache Beschleunigung läuft auf einem fetten Xeon mit 88 Cores, > während die Python-Implementierungen nur auf einem Core laufen. Sorry, > irgendwie macht das auf mich nur einen begrenzt seriösen Eindruck. Warum? Ist doch klar definiert. Man kann für low die Möglichkeiten nutzen, die ein moderner Prozessor bietet (ein 8-bitter gehört nicht dazu). Also wo ist dein Problem?
Harald K. schrieb: > Wer sich die von mir weiter oben verlinkte Webseite angesehen hat, > sollte gesehen haben, daß die ach so tolle Geschwindigkeitssteigerung > nur durch Ausnutzung von "AI-Hardware" und anderem ergibt: Ja so eine Frechheit! Die Überschrift der Seite lautet: "Mojo 🔥 — the programming language for all AI developers." Und dann läuft der Mist nur mit AI-Hardware super schnell und nicht auf dem Z80. Das ist echt ein Skandal, den du da entdeckt hast!
Re D. schrieb: > Das ist echt ein Skandal, den du da entdeckt hast! Du hast dir das Video also immer noch nicht angeschaut, gell? :)
Max M. schrieb: > Aber wie gesagt, wenn es auch nur fast so schnell wie C ist, ist es für > C /++ zumindest im Hobbybereich das Aus Für Dich vielleicht. Aber nicht für andere, die ihren vorhandenen Code weiterverwenden und ihr in Jahrzehnten erarbeitetet Wissen nicht aufgeben wollen.
MaWin O. schrieb: > Du hast dir das Video also immer noch nicht angeschaut, gell? :) Wie kommst du darauf? Die Überschrift bezieht sich im übrigen nicht auf das Video. Also ist sogar dein zitierter Bezugspunkt falsch. Also kannst du bitte beim nächsten Post irgendwas richtiges schreiben, außer deinem Namen?
Harald K. schrieb: > Aber nicht für andere, die ihren vorhandenen Code weiterverwenden und > ihr in Jahrzehnten erarbeitetet Wissen nicht aufgeben wollen. Ja, die streben aber bald, neu braucht man mit C nicht anfangen. Es kommt ja auch keiner auf die Idee was mir Dampfmaschinen als zukunftsorientierte Technologie zu verkaufen. Wer nicht mit der Zeit geht, geht mit der Zeit.
Keine Frage, dennoch würde es das Ende einleiten, da alle nachkommenden und die, die nur halbherzig seit Jahren dabei sind, dann lieber gleich auf die Universallösung setzen werden. Harald K. schrieb: > Max M. schrieb: >> Aber wie gesagt, wenn es auch nur fast so schnell wie C ist, ist es für >> C /++ zumindest im Hobbybereich das Aus > > Für Dich vielleicht. Aber nicht für andere, die ihren vorhandenen Code > weiterverwenden und ihr in Jahrzehnten erarbeitetet Wissen nicht > aufgeben wollen.
Re D. schrieb: > neu braucht man mit C nicht anfangen. C ist die Grundlage für alles. Das C ABI ist der kleinste gemeinsame Nenner aller Sprachen. Da gibt es bisher absolut keine Alternative zu. Eine Sprache, die das C ABI nicht beherrscht, ist eine Nischensprache und kann niemals universell nutzbar werden. Deshalb ist es wichtig, dass die Leute auch weiterhin die Grundlagen von C lernen.
Hier ein Podcast mit Chris Lattner, einem der Erfinder, von Mojo: https://www.youtube.com/watch?v=pdJQ8iVTwj8
MaWin O. schrieb: > Das C ABI ist der kleinste gemeinsame Nenner aller Sprachen. > Da gibt es bisher absolut keine Alternative zu. > Eine Sprache, die das C ABI nicht beherrscht, ist eine Nischensprache > und kann niemals universell nutzbar werden. Und schon wieder voll daneben. MaWin O. schrieb: > Deshalb ist es wichtig, dass die Leute auch weiterhin die Grundlagen von > C lernen. Nein, ist es nicht. 99,999% brauchen es nicht.
MaWin O. schrieb: > Re D. schrieb: >> Und schon wieder voll daneben. > > Und schon wieder keine Begründung. Es gibt Millionen Programme, die ohne "C ABI" (er definiere vielleicht genauer?) auskommen und fragt nach einer Begründung für eine offensichtlich falsche Behauptung. Lustig? Bist du Komiker und willst mich auf den Arm nehmen?
Re D. schrieb: > Ja, die streben aber bald, neu braucht man mit C nicht anfangen. Das behauptet mit praktisch jeder neuen bunten Sau, die durchs Dorf getrieben wird, immer mal wieder jemand. Seit Jahrzehnten.
Harald K. schrieb: > Das behauptet mit praktisch jeder neuen bunten Sau, die durchs Dorf > getrieben wird, immer mal wieder jemand. > Seit Jahrzehnten. Die Statistik untermauert meinen Standpunkt. Schaust du z.B. hier: https://de.statista.com/statistik/daten/studie/678732/umfrage/beliebteste-programmiersprachen-weltweit-laut-pypl-index/
Eine neue Programmiersprache zu erfinden ist keine sehr große Sache. Das kann eine Einzelperson stemmen. Wichtiger ist die Unterstützung durch Bibliotheken sowie Tools zum Entwickeln, Testen (auch Security Checks) und Projektverwaltung. Da sieht es dann ganz schnell sehr dünn aus. Selbst Google kommt da mit seinem Go und schier unendlichen finanziellen Ressourcen noch lange nicht an die zuvor etablierten Sprachen (unter anderen C) heran. Und zwar noch lange nicht.
Steve van de Grens schrieb: > auch Security Checks Steve van de Grens schrieb: > unter anderen C Der war gut, da kann sich Google mit go noch 20 Jahre Zeit lassen, wenn man mal schaut, welche lustigen Dinge allein durch Speicherüberläufe in C verursacht worden. Steve van de Grens schrieb: > Wichtiger ist die Unterstützung durch Bibliotheken sowie Tools zum > Entwickeln, Testen (auch Security Checks) und Projektverwaltung. Und genau da setzt MoJo ja offensichtlich an, nicht als neu sondern als Erweiterung von Python auftreten.
Jetzt werfe ich eine andere Theorie in die Runde: Welche Sprachen werden im embedded Bereich von den Werkzeugplatzhirschen hauptsächlich verscherbelt? https://compilerconnection.com/companies/companies.htm Wer hier schnell mal einen Blick rein wirft, findet dort predominant C/C++ vertreten und ich vermute das sich das noch lange nicht ändern wird. Gegen Massenträgheit kann man als Aussenseiter-Leichtgewichtler normalerweise eben schwer aufkommen. Und das ist vielleicht gesamt bildlich gesehen sogar gut so, denn die mühsam erworbenen Erfahrungen und das kostspielige Lehrgeld will man nicht leichtfertig über Bord werfen. Meine Prognostik: Es wird sich voraussichtlich in der absehbaren Zeit wenig ändern, wenn auch andauernd viel geredet wird und ist für die produktive Wirtschaft aber nicht unbedingt relevant. Dort will man hauptsächlich in effektiver Manier Resultate sehen.
Bestreitet niemand. Aber Python hat gezeigt, wie schnell es sich drehen kann. Und nicht jeder nutzt es beruflich, mag sein das es dort noch lange auf C laufen wird, aber wenn es erstmal im Hobbybereich Fuß fasst, wird es auch nach und nach Einzug im Profi Bereich finden, davon bin ich überzeugt, WENN es dann mal gut und fertig wird
Gerhard O. schrieb: > Welche Sprachen werden im embedded Bereich von den Werkzeugplatzhirschen > hauptsächlich verscherbelt? Und warum schränkst du das Thema auf embedded ein? Eine Nische läuft dem Hauptmarkt immer hinterher, soviel ist klar. Aber auch da wird das Thema mit etwas Verzögerung ankommen. Ich würde mal behaupten, die meiste Rechenleistung (in Summe) ist heute vermutlich auf Mobilgeräten zu finden, gefolgt von Servern und PCs. Ggf. auch umgekehrt. Embedded ist da nur eine Randerscheinung.
Gerhard O. schrieb: > https://compilerconnection.com/companies/companies.htm > Wer hier schnell mal einen Blick rein wirft, findet dort predominant > C/C++ vertreten und ich vermute das sich das noch lange nicht ändern > wird. P.S. eine Website im Stil der 90er Jahre, mit einem ©1990-2012 war vielleicht nicht der beste Beleg für deine These 😉. Belegt wohl ehr, dass deine Ansichten nicht mehr ganz up to date sind.
Re D. schrieb: > Es gibt Millionen Programme, die ohne "C ABI" (er definiere vielleicht > genauer?) auskommen Ach. Welche sind das denn so? Go-Programme vielleicht. Die linken soweit ich weiß nicht gegen libc. Sonst noch was? Praktisch alles mündet in der C ABI. Das muss man als Programmierer verstehen.
MaWin O. schrieb: > Go-Programme vielleicht Nee. Go kann C Bibliotheken aufrufen, und mit etwas Trickserei geht es auch umgekehrt.
:
Bearbeitet durch User
Re D. schrieb: > wenn > man mal schaut, welche lustigen Dinge allein durch Speicherüberläufe in > C verursacht worden. Niemand bestreitet hier hoffentlich, dass C am Ende ist und ersetzt gehört. > Und genau da setzt MoJo ja offensichtlich an, nicht als neu sondern als > Erweiterung von Python auftreten. Es reicht aber leider bei Weitem nicht aus wie Python zu sein, wenn man C ersetzen will. Das haben schon viele versucht. PyRex/Cython zum Beispiel.
MaWin O. schrieb: > Die linken soweit ich weiß nicht gegen libc Ganz falsch. Per Default nutzen alle Go Programme die Libc (dynamisch gelinkt). Man kann das aber durch eine Compiler Option deaktivieren, dann wird sie durch was eigenes ersetzt. > Praktisch alles mündet in der C ABI. Eben, und zwar auch Go.
:
Bearbeitet durch User
Steve van de Grens schrieb: > MaWin O. schrieb: >> Go-Programme vielleicht > > Nee. Go kann C Bibliotheken Das eine schließt das andere nicht aus. MaWin O. schrieb: > Praktisch alles mündet in der C ABI Ich weiß immer noch nicht, was deine C ABI sein soll. Libc ist ja wohl keine ABI. Und wo ist z.b. die ABI auf einen yC, der in ASM programmiert ist?
Steve van de Grens schrieb: > Ganz falsch. Ok. Kenne mich in Go nicht aus. Wieder was gelernt. > Per Default nutzen alle Go Programme die Libc (dynamisch gelinkt). Und dazu kommt noch, dass alle existierenden Betriebssystemschnittstellen C-ABI-ähnlich sind. Selbst ohne libc oder jede andere C-Library muss man irgendwann mal zum Betriebssystem sprechen. Die Kenntnis über C ABI, API und das C Typsystem ist essentiell für das Verständnis eines Programmablaufs. Egal in welcher Sprache. Das heißt natürlich nicht, dass man C als Programmiersprache nutzen sollte. Ganz im Gegenteil.
MaWin O. schrieb: > Es reicht aber leider bei Weitem nicht aus wie Python zu sein, wenn man > C ersetzen will. Es geht nicht darum C zu ersetzen, sondern eine Ebene darüber einzufügen, die die Verwendung von C (als Programmiersprache) in 99,x % der Fälle entbehrlich macht. Maschinencode gibt es auch noch, trotzdem programmiert man doch heute nicht auf den Level.
MaWin O. schrieb: > Dann google doch mal. https://de.m.wikipedia.org/wiki/Bin%C3%A4rschnittstelle Da steht leider nichts von "C".
Re D. schrieb: > Es geht nicht darum C zu ersetzen, sondern eine Ebene darüber > einzufügen, Ach. Also doch Kenntnis der C-ABI notwendig, wenn man mit den unteren Teilen sprechen will? > Maschinencode gibt es auch noch, trotzdem > programmiert man doch heute nicht auf den Level. Selbstverständlich tut man das. Guck doch einfach mal in die hochperformanten Teile deiner "Python"-Module rein.
Re D. schrieb: > Da steht leider nichts von "C". Du schaffst es schon noch Google richtig zu bedienen. Da bin ich zuversichtlich.
Re D. schrieb: > Da steht leider nichts von "C". Da steht ganz allgemein "Programmiersprachen", und konkret wird C++ genannt (wegen einer Besonderheit).
MaWin O. schrieb: > Ach. Also doch Kenntnis der C-ABI notwendig, wenn man mit den unteren > Teilen sprechen will? Mein Gott, wieviel % der Leute beschäftigen sich auf der Ebene noch damit, wenn das was sie eigentlich wollen so läuft? Klar kann man sich mit Compilerbau, Betriebssystemen und Maschinencode sein ganzes Leben beschäftigen. Aber das braucht halt nur eine Minderheit. Das nennt man Arbeitsteilung. MaWin O. schrieb: > Selbstverständlich tut man das. Guck doch einfach mal in die > hochperformanten Teile deiner "Python"-Module rein. Wieviel programmieren die Module und wir viele nutzen sie?
Steve van de Grens schrieb: > Da steht ganz allgemein "Programmiersprachen", Und genau deshalb, ist es nicht erforderlich C zu lernen, da es ja offensichtlich nicht zwingend C sein muss. Klar?
MaWin O. schrieb: > Du schaffst es schon noch Google richtig zu bedienen. Da bin ich > zuversichtlich. Du schaffst es nicht eine Quelle zu verlinken und bleibst in dunkeln. Deine sozialen Kompetenzen sind also ausbaufähig.
Re D. schrieb: > Mein Gott, wieviel % der Leute beschäftigen sich auf der Ebene noch > damit Spätestens wenn du eine C Bibliothek einbinden musst (eine die nicht schon eingebunden wurde), musst du dich damit auseinander setzen. Die Veröffentlichung neuer Programmiersprachen in immer kürzeren Intervallen macht es immer häufiger nötig.
Re D. schrieb: > Mein Gott, wieviel % der Leute beschäftigen sich auf der Ebene noch > damit, wenn das was sie eigentlich wollen so läuft? Klar kann man sich > mit Compilerbau, Betriebssystemen und Maschinencode sein ganzes Leben > beschäftigen. Aber das braucht halt nur eine Minderheit. Das nennt man > Arbeitsteilung. Keine Ahnung. Aber die Eigenschaften der Syscalls merkt man bis in die oberen Schichten hinein. Und genau deshalb sollte man die unteren Schichten kennen. Öffne mal eine Datei. Da fängts schon bei sowas simplem wie dem Dateipfad und der Codierung des Pfades an. Aber es geht noch viel weiter hin zu sehr subtilen Unterschieden und Verhaltensweisen. Sicher, das braucht man nicht wissen. Aber dann programmiert man halt auch Schrott in seiner schönen Hochsprachenwelt. Deshalb muss man es kennen.
Das ist halt der Unterschied zwischen Junior und Senior Entwicklern. (Damit ist nicht direkt das Alter gemeint, sondern wie tief man in der Materie steckt und wie viel Erfahrung man hat).
MaWin O. schrieb: > Öffne mal eine Datei. Da fängts schon bei sowas simplem wie dem > Dateipfad und der Codierung des Pfades an. Hast eine ziemlich allgemeine Aussage getätigt: MaWin O. schrieb: > Die Kenntnis über C ABI, API und das C Typsystem ist essentiell für das > Verständnis eines Programmablaufs. Egal in welcher Sprache. Und argumentierst nur auf Betriebssystemlevel. Da liegt das Problem. Deine Aussage könnte vielleicht lauten: "Die Kenntnis über C ABI, API und das C Typsystem ist essentiell für das Verständnis eines Programmablaufs unter aktuellen Betriebssystemen." So wird vielleicht ein Schuh draus.
Steve van de Grens schrieb: > Das ist halt der Unterschied zwischen Junior und Senior Entwicklern. > (Damit ist nicht direkt das Alter gemeint, sondern wie tief man in der > Materie steckt und wie viel Erfahrung man hat). Nein, das ist eine Frage der Spezialisierung. Man kann nicht alles und Detail beherrschen, Leute die das heute noch versuchen, sind von gestern.
Re D. schrieb: > So wird vielleicht ein Schuh draus. Aha. Ja dann. Das Betriebssystem habe ich als gegeben angenommen, wenn man Pythonähnliche Sprachen nutzt. Aber gut. Dann stimmst du mir ja doch zu.
MaWin O. schrieb: > Aber gut. Dann stimmst du mir ja doch zu. Wie gesagt, es kommt sehr darauf an, was man machen/werden möchte. In der Schule wusste ich auch genau, was der Plusquamperfekt ist. Heute weiß ich außer dem Wort nichts mehr darüber und komme gut durchs Leben. Ein Germanist sieht das vielleicht anders.
Moin,
Das Programmieren lässt sich zum Schluß einfach auf diesen Satz
ableiten:
"whatever Works!"
Gerhard
Re D. schrieb: > Die Statistik untermauert meinen Standpunkt. Schaust du z.B. hier: > [...]de.statista.com[...] Angelegentlich möchte ich gerne kurz auf eine IMHO wesentlich bessere Informationsquelle verweisen, nämlich die jährlichen Umfragen der nicht ganz unbekannten Entwicklerwebseite StackOverflow. Hier [1] findet sich eine Übersicht über die Umfragen der letzten Jahre, die aktuelle findet sich hier: [2]. Die Datensätze gibt es für eigene Analysen auch in CSV. [1] https://insights.stackoverflow.com/survey [2] https://survey.stackoverflow.co/2023/
re_(nummer) argumentiert verdächtig ähnlich wie unser allseits beliebter "Moby".
Steve van de Grens schrieb: > Wichtiger ist die Unterstützung durch Bibliotheken sowie Tools zum > Entwickeln, Testen (auch Security Checks) und Projektverwaltung. Da > sieht es dann ganz schnell sehr dünn aus. Selbst Google kommt da mit > seinem Go und schier unendlichen finanziellen Ressourcen noch lange > nicht an die zuvor etablierten Sprachen (unter anderen C) heran. Und > zwar noch lange nicht. Möglicherweise ist das ja der Grund dafür, warum Programmiersprachen wie Python, aber auch Golang und Rust jeweils Schnittstellen zu C haben, und C++ ohnehin weitestgehend abwärtskompatibel zu C ist.
Max M. schrieb: > Bestreitet niemand. Aber Python hat gezeigt, wie schnell es sich drehen > kann. Naja, schnell... die erste Version von Python wurde 1991 veröffentlicht, das ist ja nun auch schon eine Weile her. :-)
Ein T. schrieb: > Möglicherweise ist das ja der Grund Davon gehe ich mal stark aus. Im übrigen würde ich mich nicht allzu sehr von wohlwollenden Performance Test beeindrucken lasse. Es gab schon reichlich Programmiersprachen, die erheblich langsamer als C sind und sich dennoch in der Praxis bewährt gaben. Top Performance ist für die meisten Anwendungen ziemlich uninteressant.
Ein T. schrieb: > Möglicherweise ist das ja der Grund Davon gehe ich mal stark aus. Im übrigen würde ich mich nicht allzu sehr von wohlwollenden Performance Test beeindrucken lasse. Es gab schon reichlich Programmiersprachen, die erheblich langsamer als C sind und sich dennoch in der Praxis bewährt gaben. Top Performance ist für die meisten Anwendungen ziemlich irrelevant. Und wo es relevant ist, bindet man C code ein - wer hätte das gedacht?
:
Bearbeitet durch User
MaWin O. schrieb: > Ach. Welche sind das denn so? Go-Programme vielleicht. Die linken soweit > ich weiß nicht gegen libc. Sonst noch was? Go-Programme linken gegen die libc und sind dann dynamisch gelinkt, wenn sie wahlweise Netzwerkcode oder die Benutzerverwaltung verwenden. Dieser Umstand liegt daran, daß der betreffende Code in der libc über diverse Konfigurationsdateien dynamisch konfigurierbar (zum Beispiel über Name Service Switch und Pluggable Authentication Modules) sind, und daher die entsprechenden Libraries dynamisch laden müssen. Dieses Verhalten von Go läßt sich allerdings durch die Parameter "--tags netgo,netuser" ändern, dann erzeugt Go statisch gelinkte Standalone-Binaries.
Stefan F. schrieb: > Ein T. schrieb: >> Möglicherweise ist das ja der Grund > > Davon gehe ich mal stark aus. > > Im übrigen würde ich mich nicht allzu sehr von wohlwollenden Performance > Test beeindrucken lasse. Nein, das sollte man nicht tun und Du als erfahrener Entwickler weißt das natürlich auch. Benchmarks und ähnliche Performancetests sind eine sehr hohe Kunst, und mit sorgsam konstruierten Tests kann man alles beweisen, was man gerade mag. Es gibt sogar einen passend konstruierten Benchmark unter [1], in dem der Python-Interpreter Pypy schneller ist als C. > Es gab schon reichlich Programmiersprachen, die > erheblich langsamer als C sind und sich dennoch in der Praxis bewährt > gaben. ...zum Beispiel alle Skriptsprachen: man handelt Entwicklungsperformance gegen Laufzeitperformance. > Top Performance ist für die meisten Anwendungen ziemlich > uninteressant. Das habe ich hier schon einige Male geschrieben und mir dafür regelmäßig negative Bewertungen eingefangen... es ist erstaunlich, viele Mitglieder dieses Forums im High Performance Computing unterwegs sind oder für nicht genutzte Ressourcen ihr Geld zurück bekommen. :-) [1] https://www.pypy.org/posts/2011/02/pypy-faster-than-c-on-carefully-crafted-5614784244310486765.html
Harald K. schrieb: > Max M. schrieb: >> Aber wie gesagt, wenn es auch nur fast so schnell wie C ist, ist es für >> C /++ zumindest im Hobbybereich das Aus > > Für Dich vielleicht. Aber nicht für andere, die ihren vorhandenen Code > weiterverwenden und ihr in Jahrzehnten erarbeitetet Wissen nicht > aufgeben wollen. Zumal, wenn man es kann, C++ keinerlei Nachteile gegenüber C hat. Meistens kompiliert das sogar in denselben Code.
Die Hauptziel wird ja genannt: AI. Der Rest wird sich zeigen. Bezüglich der MC‘s mache ich mir keine Illusionen, die sind irgendwann mal als Abfallprodukt dabei. Schon wenn es um „normales Stromsparen“ geht, sind ARM Kerne nicht die beste Wahl, wenn darauf MicroPython läuft. Kann auch sein dass ich zu blöd bin, nur sagen die Datenblätter schon „Batterie untauglich“ vorher - außer es werden schwere Akku-Klötze rangepappt… (z.B. RP2040) An einer Kiste neben einem fetten Solarpanel ist das eher egal, nur - wie oft habe ich genau diesen Anwendungsfall mit MC‘s? Genau, eher selten.
Uwe D. schrieb: > Schon wenn es um „normales Stromsparen“ geht, sind ARM Kerne nicht die > beste Wahl, Mein iPhone Mini irgendwas kommt ein paar Tage ohne Ladegerät aus. Mit WLAN, Telefonnetz usw. Und ein fetter Akku ist nicht dran. Also so ganz passt deine Argumentation nicht.
Ein T. schrieb: > Angelegentlich möchte ich gerne kurz auf eine IMHO wesentlich bessere > Informationsquelle verweisen, nämlich die jährlichen Umfragen der nicht > ganz unbekannten Entwicklerwebseite StackOverflow. Hier [1] findet sich > eine Übersicht über die Umfragen der letzten Jahre, die aktuelle findet > sich hier: [2]. Die Datensätze gibt es für eigene Analysen auch in CSV. Und auch da ist C ja nicht wirklich der Hit, also ist die Statistik immer noch auf meiner Seite.
Diese Statistik gibt nicht die Realität wieder, sondern nur die Realität derer, die entsprechendes Quellenmaterial liefern. Wer stellt bei Stackoverflow Fragen? Einfach mal drüber nachdenken.
Hmm, grundsätzlich find ich's schon nicht ganz uninteressant. Wobei ich die angegebenen Speedup-Zahlen (ohne das Zeug getestet zu haben) erstmal als akademisch sehen würde - reale Multithreading-Anwendung vertrödeln schließlich die meiste Zeit entweder mit irgendeiner IO oder mit Synchronisation beim Warten auf irgendwelche andere Sachen... D.h. ob's denn die versprochenen Wunderdinge auch tut, wenn man z.B. bloß einfach irgendwelche Textfiles parst, muss sich eben erst zeigen. Dass es schneller als ein Python-Interpreter ist, ist erstmal ganz nett, aber wie's schon jemand gesagt hat, gibts das auch durch Cython schon bissl. Dennoch, aufgrund der Kompatibilität zu Python würd ich's schon mal mit nicht-optimierten Python-Skripts ausprobieren. Stellt sich höchstens die Frage nach dem Deployment bzw. was für tausende Abhängigkeiten an dem Mojo noch mit dranhängen, wenn man jemandem die entwickelte Software mal geben will. Bei C++ ist das relativ billig - zur Not einfach statisch kompilieren. Bei Python packste eben im Zweifelsfall sogar noch die Python-Runtimes mit dazu, sowie alle 3rdParty-Sachen, die referenziert werden. Oder will jemand nen Kunden mit pypy irgendwelche Pakete nachinstallieren lassen? Wär da ne ähnliche Deploymenthölle wie bei .net: auf dem Papier: hach, bloß die .net Runtime installieren und gut. Und in der Praxis ziehste dann noch Runtimes bis .net 2.0 hinunter hinterher... (und Docker: ja, ist nett, aber der Container will auch erstmal gebaut sein)
:
Bearbeitet durch User
Harald K. schrieb: > Diese Statistik gibt nicht die Realität wieder, sondern nur die Realität > derer, die entsprechendes Quellenmaterial liefern. Keine Statistik gibt die Realität wieder, auch die einschlägigen Indizes wie RedMonk, PYPL, TIOBE, und wie sie alle heißen. Aber die Umfragen von StackOverflow sind zweifellos eine ausgesprochen gute Quelle, wenn es um die Stimmung innerhalb der großen Community von Entwicklern geht. Genau darum geht es hier -- denn letztlich bestimmen diese Entwickler über die Zukunft ihrer Werkzeuge. > Wer stellt bei Stackoverflow Fragen? Uninteressant. Wichtiger wäre, welche Fragen gestellt werden, wie sie gestellt werden, und wer die Fragen beantwortet, denn all diese Punkte könnten die Antworten verfälschen. > Einfach mal drüber nachdenken. Mir fehlen die Zeit und vor allem auch die Lust, blöde Rätsel zu lösen. Einfach mal sagen, was Du sagen willst.
Ein T. schrieb: >> Wer stellt bei Stackoverflow Fragen? > > Uninteressant. Sehr falsch abgebogen, genau das ist der Kernpunkt. Sind das [ ] Programmieranfänger? [ ] Menschen mit Jahren oder gar Jahrzenten an Berufserfahrung? Ein T. schrieb: > und wer die Fragen beantwortet, Richtig. Aber auch hier: Sind das [ ] Programmieranfänger? [ ] Menschen mit Jahren oder gar Jahrzenten an Berufserfahrung? > denn all diese Punkte könnten die Antworten verfälschen. Na also, geht doch.
Mojo wird als Sprache für die Entwicklung von KI-Anwendungen angepriesen. Ich kann es mir durchaus auch für andere Anwendungen vorstellen, bei denen Performanz eine große Rolle spielt. Mojo ist aber keine hardwarenahe Sprache und deswegen nicht für die Bare-Metal-Programmierung (Mikrocontroller, Betriebssystems etc.) geeignet. Da C heute fast nur noch hardwarenah eingesetzt wird, wird es durch Mojo kaum verdrängt werden. Bei PC-Anwendungsprogrammen gibt es derzeit mehrere konkurrierende Sprachen, darunter C++, C#, Java und das klassische Python. Da diese nach wie vor koexistieren, ist auch kaum zu erwarten, dass Mojo eine davon verdrängt. Mojo wird, wenn überhaupt, maximal eine weitere Mainstream-Sprache unter mehreren werden. Der Vorteil von Mojo gegenüber Python liegt in der Performanz, die durch zwei Maßnahmen gesteigert wird: 1. Der Code wird in nativen Maschinencode übersetzt. Das tut aber bspw. auch das sehr viel ausgereiftere Cython. Beide entfalten ihre Geschwindigkeitsvorteile aber erst so richtig, wenn auf dynamische Typisierung verzichtet wird und alle Variablen statisch deklariert werden. Damit geht aber auch einer der wesentlichen Vorteile von Python verloren. Deswegen hat sich auch Cython nicht als vollwertiger Python-Ersatz durchgesetzt. 2. Mojo erlaubt die Nutzung von SIMD (Vektorisierung) und Multicores (Parallelisierung), was in Cython nicht oder nur eingeschränkt möglich ist. Wenn ich mir aber das Mandelbrot-Beispiel anschaue, wimmelt es da von Deklarationen und expliziten Aufrufen von SIMD-Funktionen, so dass das für mich nicht wie Python, sondern eher wie C-Code mit Python-ähnlicher Syntax aussieht. Dasselbe Programm in C wäre sogar noch etwas einfacher, da der C-Compiler in vielen Fällen die Vektorisierung automatisch übernimmt, während in Mojo dafür explizit Code geschrieben werden muss. Bis sich Mojo einen größeren Nutzerkreis erschließen kann, wird es ohnehin noch eine Weile dauern, denn derzeit ist der größte Teil der Sprache noch unimplementiert: https://docs.modular.com/mojo/roadmap.html Für mich persönlich ist in 95% aller Fälle gewöhnliches Python völlig ausreichend. In 4% aller Fälle kann das Performanzdefizit mittels Numpy, OpenCV und dergleichen behoben werden. Das verbleibende 1% erschlage ich dadurch, dass ich die ganz wenigen zeitkritischen Teile in C schreibe. Das erfordert zwar etwas Glue-Code für die Einbindung in Python, was aber dadurch kompensiert wird, dass ich mich in C nicht erst einarbeiten muss und der C-Compiler mir die SIMD-Optimierungen abnimmt. Trotzdem werde ich von Zeit zu Zeit mal auf die Mojo-Webseite gehen, nicht dass ich am Ende doch noch etwas verpasse :)
Harald K. schrieb: > Sehr falsch abgebogen, genau das ist der Kernpunkt. Nö, denn... > Sind das > > [ ] Programmieranfänger? > [ ] Menschen mit Jahren oder gar Jahrzenten an Berufserfahrung? [X] Programmieranfänger? [X] Menschen mit Jahren oder gar Jahrzenten an Berufserfahrung?
Ein T. schrieb: > [X] Menschen mit Jahren oder gar Jahrzenten an Berufserfahrung? Halte ich für unwahrscheinlich. Die haben besseres zu tun.
Harald K. schrieb: > Ein T. schrieb: >> [X] Menschen mit Jahren oder gar Jahrzenten an Berufserfahrung? > > Halte ich für unwahrscheinlich. Die haben besseres zu tun. Tja, so kann man sich irren. Oliver
Max M. schrieb: > Wenn halt auch nur ein Teil der Angaben stimmen würde, wäre es wohl die > Killersprache schlechthin und damit wohl wirklich das Aus für C / C++ > Alleine dadurch, das man nur Python lernen braucht, das MS Basic von > heute, also eine sehr leichte Programmiersprache und nur mit minimalem > Lernaufwand Mojo nutzen könnte das um Lichtgeschwindigkeiten schneller > als Python und unfassbar schneller als C / C++ wäre "unfassbar" schneller als C/C++? Wie soll das bitte gehen? Und gegenüber Leuten, die dem inflationären (hypen) Gebrauch bestimmter Vokabeln fröhnen, bin ich schonmal skeptisch... ;-) Btw.: ich sehe jetzt außer Geschwindigkeit nicht so die gravierenden Vorteile ggü. Python. Immer noch diese blöden Einrückungen als Syntaxelement(*) Ich finde nichtmal eine komplette(!) Sprachbeschreibung. Außerdem: beim Lesen bin ich über die Unterscheidung "Int" vs. "int" gestoßen. Wieso sind solche Klimmzüge zu Zeiten von KI, die eh alles von alleine löst bzw. erraten kann, notwendig? Das ist wieder so ein typischer Design Flaw. (*) Nichts gegen Python! Nach erster Ablehnung entwickle ich Tools etc. gerne mit Python. ciao Marci
Harald K. schrieb: > Ein T. schrieb: >> [X] Menschen mit Jahren oder gar Jahrzenten an Berufserfahrung? > > Halte ich für unwahrscheinlich. Die haben besseres zu tun. Tja -- da sehen wir mal wieder mal, wie wenig Ahnung Du hast.
Max M. schrieb: > Bestreitet niemand. Aber Python hat gezeigt, wie schnell es sich drehen > kann. Hmmmm, was genau hat "Python schnell gedreht"? ciao Marci
Ein T. schrieb: > Tja -- da sehen wir mal wieder mal, wie wenig Ahnung Du hast. Klar, Menschen mit Berufserfahrung haben nichts besseres zu tun, als auf Stackoverflow rumzuhängen und Anfängerfragen zu beantworten. Muss so sein, weil Du es sagst.
Harald K. schrieb: > Klar, Menschen mit Berufserfahrung haben nichts besseres zu tun, als auf > Stackoverflow rumzuhängen und Anfängerfragen zu beantworten. Muss so > sein, weil Du es sagst. Du hast Recht. Das gleiche gilt für dieses Forum. Hier gibt es Dilettanten und Schwätzer, aber kaum jemand mit substantieller Berufserfahrung. Deshalb wird hier so viel Müll geschrieben, die Deppen klatschen sich Beifall. Also C ist das beste und nichts kann es ersetzen! Umfragen nach denen Java oder Python als beliebteste Sprache ausweisen, sind falsch, da werden einfach die falschen Leute gefragt.
Harald K. schrieb: > Klar, Menschen mit Berufserfahrung haben nichts besseres zu tun, als auf > Stackoverflow rumzuhängen und Anfängerfragen zu beantworten. Muss so > sein, weil Du es sagst. Ja, äh... [ ] Du kennst StackOverflow.
Re D. schrieb: > Umfragen nach denen > Java oder Python als beliebteste Sprache ausweisen, sind falsch, da > werden einfach die falschen Leute gefragt. Jetzt mach' aber bitte mal halblang, irgendwie muß er sich seine Ansichten ja schönreden. Sonst fällt ihm hinter noch selbst auf, wie "fundiert" das ist, womit er uns hier so gerne "beglückt". Aber das Beste an seinen "weisen" Sprüchen versteht man, wenn man seine "Weisheiten" auf ihn selbst anwendet und feststellt, daß er die Zeit dazu hatte, in den letzten 648 Tagen hier 2509 "Beiträge" abzusondern. Zu den Experten mit "Jahrzenten an Berufserfahrung" gehört er also offensichtlich nicht, denn die haben seinen eigenen Aussagen zufolge gar keine Zeit zur Teilnahme an Foren wie StackOverflow oder natürlich diesem hier...
Re D. schrieb: > Uwe D. schrieb: >> Schon wenn es um „normales Stromsparen“ geht, sind ARM Kerne nicht die >> beste Wahl, > > Mein iPhone Mini irgendwas kommt ein paar Tage ohne Ladegerät aus. Mit > WLAN, Telefonnetz usw. Und ein fetter Akku ist nicht dran. Also so ganz > passt deine Argumentation nicht. Hast Du den dazu gehörenden Kontext gelesen? Keine Ahnung weshalb Du jetzt mit einem iPhone um die Ecke kommst. Dein iPhone hat wohl einen fetten Akku. Oder willst Du mir jetzt erzählen, da wären 500mAh drin verbaut? _Guckst Du hier:_ https://www.macwelt.de/article/986562/iphone-so-viel-akku-kapazitaet-hat-jedes-einzelne-modell.html Nur ging es mir ja im Sinne des Forums um sparsamen MC‘s und nicht um Rechenleistung auf (fast) Desktop Niveau…
Re D. schrieb: > Harald K. schrieb: >> Klar, Menschen mit Berufserfahrung haben nichts besseres zu tun, als > Also C ist das beste und nichts kann es ersetzen! Umfragen nach denen > Java oder Python als beliebteste Sprache ausweisen, sind falsch, da > werden einfach die falschen Leute gefragt. Hast Du ein Problem damit, dass die offensichtliche Mehrheit sich anders entscheidet? Wer sollen die „falschen Leute“ sein? Keine Ahnung, warum immer alles in Schubladen geschoben werden muss.
Uwe D. schrieb: > Hast Du ein Problem damit, dass die offensichtliche Mehrheit sich anders > entscheidet? Die "falschen Leute" sind genau jene Mehrheit, die Python (oder Java oder Golang oder Rust) mögen, also irgend etwas, das der Harald nicht kann und deshalb auch nicht leiden kann.
Uwe D. schrieb: > Hast Du ein Problem damit, dass die offensichtliche Mehrheit sich anders > entscheidet? Du hast ein Problem mit Ironie, würde ich sagen.
Uwe D. schrieb: > Dein iPhone hat wohl einen fetten Akku. Oder willst Du mir jetzt > erzählen, da wären 500mAh drin verbaut? Da ist Fett wohl eine Definitionsfrage. Es ist sehr viel handlicher als ein NF-Ziegel und ist für die Mehrheit wohl handlich. Für echte Männerhände ist es zu klein.
Re D. schrieb: > Also C ist das beste und nichts kann es ersetzen! Umfragen nach denen > Java oder Python als beliebteste Sprache ausweisen, sind falsch Was das die "beste" oder die "beliebteste" Programmiersprache ist, spielt doch gar keine Rolle. Bei Internet Diskussionen wage ich sogar zu behaupten, dass Probleme mit einer Programmiersprache das Ranking nach oben beeinflussen. Deswegen sind sie wohl kaum besser. Für mich ist relevant, welche Programmiersprache ich zum Arbeiten benutzen soll. Da hatte ich nämlich nur in sehr wenigen Einzelfällen die freie Wahl. Für meine Mikrocontroller beim Hobby nutze ich dann natürlich bevorzugt eine Programmiersprache, die ich schon kann. Das ist in meinem Fall C++ und als Nebeneffekt auch C. Auf der Arbeit habe ich überwiegend in Java und Go zu. Sind das meine Lieblings-Sprachen?: Nein Halte ich sie für die besten Programmiersprachen?: Nein Wenn ich im Internet über Programmiersprachen schreibe, sind es dennoch zu 99,9% diese vier. Welche Sprache finde optimal oder am besten?: Kann ich nicht sagen. Jede hat ihren Schwerpunkt und ihre Mängel. Außerdem habe ich nur ungefähr 12 Sprachen beruflich eingesetzt, ich kenne also nicht alle. Noch bin ich jedenfalls auf keine gestoßen, mit der ich mich verheiraten möchte. Sie taugen alle nur als Werkzeug, nicht als Liebling.
:
Bearbeitet durch User
Max M. schrieb: > Ist MoJo hier um zu bleiben? Ersetzt es C,C++, Python etc? Ist das tatsächlich closed source? LG, Sebastian
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.