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
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
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
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
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?
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.
Max M. schrieb: > Ist MoJo hier um zu bleiben? Ersetzt es C,C++, Python etc? Ist das tatsächlich closed source? LG, Sebastian
Sebastian W. schrieb: > Ist das tatsächlich closed source? Derzeit, ja. Was die Zukunft bringen wird, ist unklar: https://docs.modular.com/mojo/faq.html#open-source Fest steht aber: Die Firma entwickelt derzeit zwei Produkte (AI Engine und Mojo) und muss mindestens 5 Investoren bei Laune halten (deswegen wohl auch der etwas marktschreierische Web-Auftritt). Irgendwann wollen die Investoren natürlich auch Umsatz sehen, und den generiert man nicht, indem man von den ohnehin nur wenigen Produkten auch noch einen Teil verschenkt.
Yalu X. schrieb: > Derzeit, ja. Was die Zukunft bringen wird, ist unklar: Ja ne. Unklar ist das nicht. Das ist einfach nur Marketinggelaber, um die Open-Source-Community nicht komplett zu verschrecken. Die Karotte wird vor dem Esel hergetragen. Fakt ist aber, dass in der heutigen Zeit eine Closed-Source-Sprache maximal in einer Nische Anwendung finden wird. Die Leute sind halt nicht mehr ganz bescheuert.
MaWin O. schrieb: > Yalu X. schrieb: >> Derzeit, ja. Was die Zukunft bringen wird, ist unklar: > > Ja ne. Unklar ist das nicht. > Das ist einfach nur Marketinggelaber, um die Open-Source-Community nicht > komplett zu verschrecken. > Die Karotte wird vor dem Esel hergetragen. Warum sollten die Mojo-Entwickler die Karotte vor dem Esel hertragen, wenn sie genau wüssten, dass sie sie dem Esel die Karotte nie zum Fressen geben werden? Aus reiner Boshaftigkeit? > Fakt ist aber, dass in der heutigen Zeit eine Closed-Source-Sprache > maximal in einer Nische Anwendung finden wird. Nicht die Sprache ist Closed-Source, sondern höchstens der Compiler, und unter den Compilern gibt es durchaus welche, die nicht Open-Source, ja nicht einmal kostenlos sind, und sich dennoch größerer Beliebtheit erfreuen.
Yalu X. schrieb: > Nicht die Sprache ist Closed-Source, sondern höchstens der Compiler Solange es keinen Open-Source-Compiler gibt, macht das exakt genau Null Unterschied.
MaWin O. schrieb: > Solange es keinen Open-Source-Compiler gibt, macht das exakt genau Null > Unterschied. Ob ein Startup (=Klitsche) da jetzt noch eine Sprache vorstellt, ist doch eh völlig belanglos, egal, ob Open Source oder nicht. Relevant wird sowas, wenn google, Meta, Microsoft/OpenAI, oder einer der ganz wenigen anderen großen die für ihre internen AI Projekte einsetzen würde. Passiert das nicht, bleibt das einfach nur eine weitere unbedeutende Randnotiz in der Geschichte der IT. Solange dem Großteil der Menschheit bei Mojo Austin Powers einfällt, wird das mit der Sprache nix. Oliver
:
Bearbeitet durch User
Oliver S. schrieb: > Relevant wird > sowas, wenn google, Meta, Microsoft/OpenAI, oder einer der ganz wenigen > anderen großen die für ihre internen AI Projekte einsetzen würde. Google setzt für die Cloud vorzugsweise Go ein. Dennoch ist Go weitgehend unbekannt. Da muss schon mehr passieren, um zum großen Erfolg zu kommen. https://cloud.google.com/go?hl=de
Stefan F. schrieb: > Dennoch ist Go > weitgehend unbekannt. Nun ja, vorzugsweise und weitgehend sind da wohl vorzugsweise weitgehend unzutreffend… Nichtsdestotrotz kommt die Sprache im Ranking gleich nach den richtig großen. Oliver
Spannend wäre die Frage zu beantworten, mit welcher Sprache am meisten Geld verdient wird. Aus der Perspektive ist auch ein 6. Platz in der Beliebtheitsskala völlig Rille, wenn ich im Schnitt das 3-fache wie „die erste Sprache“ verdiene.. Es könnte aber auch sein, dass Python genau deshalb (Wirtschaftlichkeit) so weit vorne liegt. Ein Argument, dass bei Könnern u.U. Unbehagen auslöst.
Uwe D. schrieb: > mit welcher Sprache am meisten Geld verdient wird. Wie soll man das denn bitte messen? Und was soll das überhaupt bringen? Wenn ich mit 10 Zeilen C-Code Milliarden Euros verdiene, weil ich das Produkt nur oft genug verkaufe, welchen Rückschluss soll das auf die Sprache geben? Wenn ich mir 100 Zeilen Python-Code nur eine Million Euro verdiene, ist Python dann schlechter? Uwe D. schrieb: > Es könnte aber auch sein, dass Python genau deshalb > (Wirtschaftlichkeit) so weit vorne liegt. Ein Argument, dass bei Könnern > u.U. Unbehagen auslöst. Gerade bei Software hängt die Geldmenge, die man verdienen kann, nicht in erster Linie von der Entwicklungszeit ab, sondern von der Anzahl der verkauften Instanzen. Gerade bei Sprachen wie Python schlagen die Performancenachteile irgendwann ganz ganz bitter zurück, wenn man das Unternehmen hochskaliert. Man hat zwar einmal etwas Geld bei der Entwicklung gespart, muss aber dauerhaft die 10-fache Serverleistung zur Verfügung stellen. (Oder man gibt wie Meta und Co wieder massenhaft Geld aus, um Python zu optimieren)
MaWin O. schrieb: > Gerade bei Software hängt die Geldmenge, die man verdienen kann, nicht > in erster Linie von der Entwicklungszeit ab, sondern von der Anzahl der > verkauften Instanzen. Gemeint war wohl eher die Verdienstmöglichkeit für den gemeinen Code-Tagelöhner. Oliver
MaWin O. schrieb: > Uwe D. schrieb: >> mit welcher Sprache am meisten Geld verdient wird. > > Wie soll man das denn bitte messen? > Und was soll das überhaupt bringen? Das sagt etwas über die Kosten und natürlich den Profit. Und dass sich offensichtlich mit den umsatzstarken Sprachen gut die Ziele der zu entwickelnden Software erreichen lassen. Begriffe wie RAMS (Reliability, Availability, Maintainability, Safety) oder Nachhaltigkeit (Dein Beispiel: zu viele Server) > Wenn ich mit 10 Zeilen C-Code Milliarden Euros verdiene, weil ich das > Produkt nur oft genug verkaufe, welchen Rückschluss soll das auf die > Sprache geben? Das Du das richtige Werkzeug für ein zu entwickelndes Produkt eingesetzt hast. > Wenn ich mir 100 Zeilen Python-Code nur eine Million Euro verdiene, ist > Python dann schlechter? Die Frage ist irgendwie komisch… Vergleichbarkeit: Wieviele Zeilen Code brauche ich für das in C geschriebene Produkt und wie ist es qualitativ einzuordnen. > > Uwe D. schrieb: >> Es könnte aber auch sein, dass Python genau deshalb >> (Wirtschaftlichkeit) so weit vorne liegt. Ein Argument, dass bei Könnern >> u.U. Unbehagen auslöst. > > Gerade bei Software hängt die Geldmenge, die man verdienen kann, nicht > in erster Linie von der Entwicklungszeit ab, sondern von der Anzahl der > verkauften Instanzen. Das ist nur dann richtig, wenn Du die Software verkaufen willst. Wenn Du aber selbst der Konsument bist, dann ist der Lizenzverkauf nachrangig. > Gerade bei Sprachen wie Python schlagen die Performancenachteile > irgendwann ganz ganz bitter zurück, wenn man das Unternehmen > hochskaliert. Man hat zwar einmal etwas Geld bei der Entwicklung > gespart, muss aber dauerhaft die 10-fache Serverleistung zur Verfügung > stellen. (Oder man gibt wie Meta und Co wieder massenhaft Geld aus, um > Python zu optimieren) Du brauchst dann eben Entwickler die verstehen was gemacht werden soll und zwar schnell (ein Widerspruch für klassische Projekte) und mit sich schnell ändernden Anforderungen… Diesen Kommunikationsengpass umgeht man mit Sprachen wie Python ganz gut, weil Nicht-IT‘ler damit klarkommen und sich einarbeiten. Insofern würde Mojo wieder eine spezielle Zielgruppe ansprechen.
MaWin O. schrieb: > 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 > Ö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 Siehst Du das bei typischen Web-Apps (Cloud) auch so?
Uwe D. schrieb: > Spannend wäre die Frage zu beantworten, mit welcher Sprache am meisten > Geld verdient wird. Im Fintech-Umfeld sind das vermutlich die Coboleros. Dafür gibt es nicht mehr so viele, dafür aber viel alten Code, der gepflegt werden muß.
MaWin O. schrieb: > Gerade bei Software hängt die Geldmenge, die man verdienen kann, nicht > in erster Linie von der Entwicklungszeit ab, sondern von der Anzahl der > verkauften Instanzen. Die Entwicklungskosten hängen jedoch wesentlich von der Entwicklungszeit und der Zahl der nötigen Entwickler ab. Und das bestimmt dann wieder die benötigen Investitionssummen und den Zeitpunkt, wann der Break Even Point erreicht werden kann. Wenn Du dann mit Kosten für Server ankommst, wird offensichtlich, daß Du nicht verstanden hast, daß jedes Geschäftsmodell, bei dem das über den Erfolg entscheidet, schon lange gescheitert ist. Meine Güte, für ein Jahresgehalt eines Entwicklers kann ich über 100 sehr gut ausgestattete Server mit allem mieten.
Some O. schrieb: > wird offensichtlich, daß Du nicht verstanden hast, Aha. Dann denken Meta und alle anderen Firmen, die Python massiv einsetzen, sich das wohl nur aus. Google danach. Das sind echte Probleme. Da gibt es viele Artikel drüber. Dynamisch typisiertes Python skaliert nicht. Sowohl in der Laufzeit, als auch in der Maintainability der Codebasis. Entwicklungskosten gehen additiv in die Kosten rein. Serverlaufzeiten gehen multiplikativ mit der Nutzerbasis in die Kosten rein. Maintenancekosten gehen teilweise exponentiell mit der Codekomplexität in die kosten rein. Sowohl bei Laufzeit als auch bei Maintenance ist dynamisch typisiertes Python die Hölle.
:
Bearbeitet durch User
Ein T. schrieb: > Im Fintech-Umfeld sind das vermutlich die Coboleros. Dafür gibt es nicht > mehr so viele, dafür aber viel alten Code, der gepflegt werden muß. Schon mal darüber nachgedacht, das des einen Verdienst des anderen Kosten sind? Man könnte also sagen, die Coboleros kosten am meisten.
Re D. schrieb: > Schon mal darüber nachgedacht, das des einen Verdienst des anderen > Kosten sind? Man könnte also sagen, die Coboleros kosten am meisten. Auch du machst den gleichen Fehler. Kosten sind immer in Relation zum Umsatz zu sehen. Wenn der Unternehmer mit der Cobol-App im Jahr 100 Million Euro Gewinn einfährt, weil es z.B. die Basis seines Geschäftsbetriebes ist, dann ist es ziemlich unerheblich, ob der Experten-Entwickler davon 50k, 100k oder 150k bekommt.
MaWin O. schrieb: > Dynamisch typisiertes Python skaliert nicht. Sowohl in der Laufzeit, als > auch in der Maintainability der Codebasis. Wenn ich danach suche finde ich vorrangig Unsinn. Ich wüsste aich ehrlich nicht, warum dynamische Typen laufzeitmäßig weniger skalieren sollte als statische. LG, Sebastian
Re D. schrieb: > Ein T. schrieb: >> Im Fintech-Umfeld sind das vermutlich die Coboleros. Dafür gibt es nicht >> mehr so viele, dafür aber viel alten Code, der gepflegt werden muß. > > Schon mal darüber nachgedacht, das des einen Verdienst des anderen > Kosten sind? Nein. Wer darüber nachdenken muß, ist hier fehl am Platze. > Man könnte also sagen, die Coboleros kosten am meisten. Das war nicht die Frage.
Sebastian W. schrieb: > MaWin O. schrieb: >> Dynamisch typisiertes Python skaliert nicht. Sowohl in der Laufzeit, als >> auch in der Maintainability der Codebasis. > > Wenn ich danach suche finde ich vorrangig Unsinn. Ich wüsste aich > ehrlich nicht, warum dynamische Typen laufzeitmäßig weniger skalieren > sollte als statische. Zumal Python gar nicht dynamisch typisiert ist.
Ein T. schrieb: > Nein. Wer darüber nachdenken muß, ist hier fehl am Platze. Wieso sollte man das sein? MaWin O. schrieb: > Auch du machst den gleichen Fehler. > Kosten sind immer in Relation zum Umsatz zu sehen. Leider falsch, im BWL nicht aufgepasst?
MaWin O. schrieb: > Some O. schrieb: >> wird offensichtlich, daß Du nicht verstanden hast, > > Dann denken Meta und alle anderen Firmen, die Python massiv einsetzen, > sich das wohl nur aus. Sie setzen Python aber trotzdem ein, sogar "massiv". Und wenn Du auch nur halb so klug wärst, wie Du es gerne glaubst, dann würdest Du jetzt mal gaaanz intensiv darüber nachdenken, warum die das wohl tun. > Google danach. Das sind echte > Probleme. Da gibt es viele Artikel > drüber. Ich finde sicher auch Artikel, die beweisen, daß die Erde eine Scheibe ist und die Sonne sich darum dreht. > Dynamisch typisiertes Python skaliert nicht. Doch, tut es, je nach Anwendungsfall gibt es da mehrere Wege. Nur weil Du die nicht kennst, verschwinden die ja nicht. Und: Python ist übrigens gar NICHT dynamisch typisiert... > Sowohl in der Laufzeit, als > auch in der Maintainability der Codebasis. Ein Blinder faselt von Farben und ich soll auch noch nach Belegen für sein Gefasel googeln. Hast Du sie noch alle? > Entwicklungskosten gehen additiv > Serverlaufzeiten gehen multiplikativ > Maintenancekosten gehen teilweise exponentiell Bei uns bezeichnet man derart naive "Berechnungs"methoden meistens als "KHV-kompatibel", "KHV" steht für "Kinder, Hausfrauen, Vorstände". Und als Nächstes willst Du mir noch erklären, daß die Komplexität in C geringer sei als in Python, ja? > Sowohl bei Laufzeit als auch bei Maintenance ist dynamisch typisiertes > Python die Hölle. Nö, und Du hast wirklich überhaupt nichts außer dummen Vorurteilen und einer großen Klappe. Dazu nur ein Beweis: im Gegensatz zu beispielsweise Perl und PHP ist Python nämlich gar nicht dynamisch typisiert. Da kiekste, wa? Wenn Du auch nur ein Hundertstel der Ahnung hättest, die Du zu haben glaubst, wüßest Du das und würdest nicht so einen wirren Unfug erzählen. Aber hier den Lauten machen, weißte.
Doch, Python typisiert dynamisch. https://de.wikipedia.org/wiki/Dynamische_Typisierung Erinnert mich an Sprachen wie https://de.wikipedia.org/wiki/Clipper_(Programmiersprache), das war das Gegenteil von dem was z.B. Pascal von mir wollten…
Some O. schrieb: > Ich finde sicher auch Artikel, die beweisen, daß die Erde eine Scheibe > ist und die Sonne sich darum dreht. Ja gut. Wenn das deine Argumentationsweise ist, dann ist das halt so. Da antworte ich nicht mehr drauf.
Ein T. schrieb: > Zumal Python gar nicht dynamisch typisiert ist. Was dann? Statisch? Oder gibt es noch eine dritte Möglichkeit? Some O. schrieb: >> Dynamisch typisiertes Python skaliert nicht. > > Doch, tut es, ... > ... > Und: Python ist übrigens gar NICHT dynamisch typisiert... Interessante Logik ;-)
Yalu X. schrieb: > Interessante Logik ;-) Ich sehe immer noch nicht, wie die Art und Weise der Behandlung von Datentypen die Skalierbarkeit beeinflussen soll. Klar sind statische Typen besser optimierbar, insofern ist die Grundperformance womöglich besser, aber von dieser Grundperformance ausgehend sollte die Skalierbarkeit doch gleich sein. Oder wie? LG, Sebastian
Sebastian W. schrieb: > aber von dieser Grundperformance ausgehend sollte die > Skalierbarkeit doch gleich sein. Oder wie? In der Praxis nicht. Nein. Das die Skalierbarkeit gleich wäre, würde nur gelten, wenn es keine praktischen Limits und Quantisierungen geben würde. Rechenpower bekommt man nur in quantisierten Einheiten und ist räumlich und monetär begrenzt. Wenn ich wegen der schlechten "Grundperformance" nur 10 Server statt 100 pro Rechner betreiben kann, dann skaliert das in meinem Betreibergeldbeutel ganz schlecht. Der ist nämlich limitiert. Die "Grundperformace" von dynamisch typisierten Sprachen liegt halt um Größenordnungen unter der "Grundperformance" von statisch typisierten Sprachen. Man kommt da halt deutlich schneller an die Skalierungsgrenzen der Physik und der monetären Mittel.
MaWin O. schrieb: > Die "Grundperformace" von dynamisch typisierten Sprachen liegt halt um > Größenordnungen unter der "Grundperformance" von statisch typisierten > Sprachen. Nur ist in der Praxis diese "Grundperformance" nicht so relevant. Viel relevanter ist die tatsächliche Performance einer in einer Sprache geschriebenen Anwendung. Und da sind andere Dinge wichtiger. Zum Beispiel der Ausbildungsstand der entsprechenden auf dem Markt verfügbaren Programmierer, oder die Mächtigkeit des Ökosystems der Sprache, um nur zwei Dinge zu nennen. Ich finde dazu folgende Studie nach wie vor interessant https://page.mi.fu-berlin.de/prechelt/Biblio/jccpprtTR.pdf, in der empirisch Python performanter als Java ist. Ist natürlich auch nur ein künstliches Beispiel, soll also hier nur das Prinzip verdeutlichen. LG, Sebastian
MaWin O. schrieb: > Ein T. schrieb: >> Zumal Python gar nicht dynamisch typisiert ist. > > Jetzt wirds aber wild hier. :) Kein bisschen.
Yalu X. schrieb: > Ein T. schrieb: >> Zumal Python gar nicht dynamisch typisiert ist. > > Was dann? Statisch? Oder gibt es noch eine dritte Möglichkeit? Duck typing: nicht die Variablennamen sind typisiert, sondern die Werte. Einfacher Test:
1 | 1 + "1" |
einmal in PHP, in Perl, in Ruby und in Python ausführen und das Ergebnis ausgeben lassen. PHP und Perl geben 2 aus, Ruby und Python beschweren sich dagegen wegen eines Typfehlers.
MaWin O. schrieb: > Some O. schrieb: >> Ich finde sicher auch Artikel, die beweisen, daß die Erde eine Scheibe >> ist und die Sonne sich darum dreht. > > Ja gut. Wenn das deine Argumentationsweise ist, dann ist das halt so. Da > antworte ich nicht mehr drauf. Keine Ahnung, was seine Argumentationsweise ist. Aber Deine ist auch nicht viel besser: erst etwas behaupten und dann "google doch mal" zu sagen, ist mindestens genauso unterirdisch.
Ein T. schrieb: > Yalu X. schrieb: >> Ein T. schrieb: >>> Zumal Python gar nicht dynamisch typisiert ist. >> >> Was dann? Statisch? Oder gibt es noch eine dritte Möglichkeit? > > Duck typing: Duck Typing gehört einer anderen Kategorie von Typsystemeigenschaften an. Solche Kategorie sind bspw.: - static – dynamic - strong – weak - manifest – inferred - nominal – structural – duck – ... - ... Ein Typsystem kann also sowohl dynamic als auch duck sein. > nicht die Variablennamen sind typisiert, sondern die Werte. Das haben dynamische Typsysteme naturgemäß so an sich. > Einfacher Test: > 1 + "1" > > einmal in PHP, in Perl, in Ruby und in Python ausführen und das Ergebnis > ausgeben lassen. PHP und Perl geben 2 aus, Ruby und Python beschweren > sich dagegen wegen eines Typfehlers. Hier sprichst du die Kategorie strong – weak an: Python ist stärker typisiert (stronger) als Perl (weaker). Das hat aber weder mit dem dynamic noch mit duck etwas zu tun, weil es sich jeweils um verschiedene Kategorien handelt.
:
Bearbeitet durch Moderator
MaWin O. schrieb: > Wenn ich wegen der schlechten "Grundperformance" nur 10 Server statt 100 > pro Rechner betreiben kann, dann skaliert das in meinem > Betreibergeldbeutel ganz schlecht. Der ist nämlich limitiert. Ach MaWin, doch mal ein Semester BWL? 1. Ist nicht die Frage wie viele Server ich betreiben kann, sonder wie viele ich betreiben muss. 2. Sind in Gegensatz zu dem Entwickler die Betriebskosten der Server tatsächlich variable Kosten und sind im Bezug zum Umsatz zu betrachten.
Okay, da scheint niemand anders etwas sagen zu wollen, und die Antwort könnte vielleicht dennoch interessant sein... Yalu X. schrieb: > Ein T. schrieb: > Duck Typing gehört einer anderen Kategorie von Typsystemeigenschaften > an. > > Solche Kategorie sind bspw.: > > - static – dynamic > - strong – weak > - manifest – inferred > - nominal – structural – duck – ... > - ... In den letzten 35 Jahren sind mir so viele Definitionen für Eigenschaften von Typsystemen untergekommen... Vor einigen Jahren habe ich mal die, wie ich finde, recht treffende Definition für ein dynamisches System gelesen, daß der Interpreter zur Laufzeit versucht, die Operatoren dynamisch an die Operation anzupassen, so daß Dinge wie
1 | 1 + '1' |
möglich werden -- wie es PHP und Perl klaglos ausführen, Python und Ruby hingegen mit einer Fehlermeldung verweigern. Sowas kann eine ausgesprochen subtile Quelle für logische Fehler sein. >> nicht die Variablennamen sind typisiert, sondern die Werte. > > Das haben dynamische Typsysteme naturgemäß so an sich. Ja, diese Definition kenne ich auch... Wie dem auch sei, ist die Unterscheidung für Python nicht ganz einfach, denn dort bestimmt der Entwickler darüber, welcher Grad an Typsicherheit benötigt und erzielt wird. Zunächst sind Typinformationen in Form von Type Hints und Annotations bereits seit sehr langer Zeit fester Bestandteil des Sprachkerns, dazu wurde mit Python 3.0 eigens die Syntax erweitert. Während es also noch immer vollkommen legal ist,
1 | def add(a, b): |
2 | return a + b |
3 | |
4 | print(add(3, 4)) |
5 | print(add("eins", "zwei"))
|
zu schreiben und diese Operation mit beliebigen Kombinationen von Integer, Float und Komplexen Zahlen auszuführen, könnte sie aber auch einfach mit zwei Strings aufgerufen werden und sie konkatenieren. Sofern dann keine weiteren Maßnahmen ergriffen werden, funktioniert das auch mit der annotierten Version der Funktion:
1 | from typing import Union |
2 | |
3 | Numeric = Union[int, float, complex] |
4 | |
5 | def add(a: Numeric, b: Numeric) -> Numeric: |
6 | return a + b |
7 | |
8 | print(add(3, 4)) |
9 | print(add("eins", "zwei"))
|
Ausgabe: -- snip ----- 7 einszwei -- snap ----- Ja Huch: str unterstützt die Methode __add__() zum Konkatenieren. Nichtsdestotrotz kann ich natürlich dafür sorgen, daß eine statische Typprüfung stattfindet, genau so wie ein Compiler in einer statisch typisierten Sprache das zur Compilezeit macht. Dazu gibt es letztlich verschiedene Möglichkeiten: entweder mit mypy -- also im Grunde einen separaten Schritt zwischen Entwicklungs- und Laufzeit einbauen -- oder während der Laufzeit mit typeguard:
1 | from typing import Union |
2 | from typeguard import typechecked |
3 | |
4 | Numeric = Union[int, float, complex] |
5 | |
6 | @typechecked |
7 | def add(a: Numeric, b: Numeric) -> Numeric: |
8 | return a + b |
9 | |
10 | print(add(1, 3.2)) |
11 | print(add("eins", "zwei"))
|
Dieser letzte Code springt mir zur Laufzeit ins Gesicht, weil "eins" (und "zwei") natürlich keine Numerics sind. Zur Laufzeit ist natürlich nicht so schön, wie die Freunde von Sprachen mit statischen Typsystemen natürlich sagen werden, und damit sogar Recht haben. Okay, mypy to the rescue: das ist ein statischer Typchecker und prüft die Typen vor der Laufzeit, aber natürlich in einem separaten Schritt, und auch mypy findet den Fehler. Das ist dann ganz ähnlich zur Typprüfung in statisch typisierten Sprachen. Obendrein unterstützt Python eine enorm starke und dynamische Reflection API, so daß punktuell notwendige Typprüfungen (auch für Python 2) etwa mit dem Builtin isinstance() durchgeführt werden können. Auch das Python-Modul attrs bietet starke Möglichkeiten der Typprüfung für Instanzeigenschaften von Klassen. Andere Python-Module bieten bereits inhärente Typsicherheit, zum Beispiel die numpy-Bibliotheken und alles, was darauf aufbaut... Jetzt könnte man natürlich sagen, naja, Python macht das ja nicht immer, und die Typprüfung braucht zusätzliche externe Software. Während das ja zweifellos korrekt ist, sind die wesentlichen Grundlagen, nämlich Type Hints und Annotations, fester Bestandteil der Sprache. Darüber könnte man noch stundenlang diskutieren, aber am Ende ist Python auch in diesem Punkt ebenso konsequent flexibel wie sonst, und bietet mir als Entwickler genau den Grad an Typsicherheit, den ich haben möchte. Insofern möchte ich meine Aussage von oben präzisieren: Python ist so lange dynamisch typisiert, wie ich das haben möchte. Am Rande: in kleinen Wegwerfskripte sind Type Hints und Annotations wohl nicht besonders sinnvoll, aber für alles, für das sich Unittests lohnen, sind sie aus Dokumentationsgründen auch dann sehr sinnvoll, wenn man gar keine Typprüfungen damit machen will...
Ein T. schrieb: > In den letzten 35 Jahren sind mir so viele Definitionen für > Eigenschaften von Typsystemen untergekommen... Siehste. Man kann immer was dazulernen. > Vor einigen Jahren habe > ich mal die, wie ich finde, recht treffende Definition für ein > dynamisches System gelesen, daß der Interpreter zur Laufzeit versucht, > die Operatoren dynamisch an die Operation anzupassen, so daß Dinge wie Das ist schwache Typisierung. Python ist stark-dynamisch typisiert. Wenn in Python ein Objekt dynamisch entsteht, dann ist dessen Typ fest und eindeutig. Ein String ist eben kein int. Ein Typ A kann sich in Einzelsituationen oder insgesamt so verhalten als wäre er Typ B, falls er so implementiert ist. Das nennt sich dann Duck. Er ist und bleibt jedoch Typ A. Ein Duck ist immer eindeutig zu entlarven mit type() und isinstance(). Ein T. schrieb: > Jetzt könnte man natürlich sagen, naja, Python macht das ja nicht immer, > und die Typprüfung braucht zusätzliche externe Software. Ja. Aber trotzdem hat ein Objekt zu jeder Zeit immer einen ganz exakten Typ. Ganz im Gegensatz zu zum Beispiel schwach typisierten Perl, wo der Typ vom Verwendungskontext abhängt. So. Das war dann aber genug Off-Topic hier für mich :)
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.