Forum: Compiler & IDEs Ist MoJo hier um zu bleiben? Ersetzt es C,C++, Python etc?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Max M. (Gast)


Lesenswert?

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

von Harald K. (kirnbichler)


Lesenswert?

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

von Max M. (Gast)


Lesenswert?

Das youtube kann man aber nebenbei hören;-)

von MaWin O. (mawin_original)


Lesenswert?

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?

von Max M. (Gast)


Lesenswert?

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

von Harald K. (kirnbichler)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

Am schönsten am Video finde ich ja, welches Logo er für Rust gewählt hat 
;)

von Re D. (Gast)


Lesenswert?

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?

von Re D. (Gast)


Lesenswert?

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.

von Hannes J. (Firma: _⌨_) (pnuebergang)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von Re D. (Gast)


Lesenswert?

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?

von MaWin O. (mawin_original)


Lesenswert?

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?

von Re D. (Gast)


Lesenswert?

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.

von Max M. (Gast)


Lesenswert?

Kinders, geht es auch sachlicher.
Schreibt das doch per PN

von Harald K. (kirnbichler)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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...

von Max M. (Gast)


Lesenswert?

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

von Ein T. (ein_typ)


Lesenswert?

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...

von Re D. (Gast)


Lesenswert?

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?

von Re D. (Gast)


Lesenswert?

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!

von MaWin O. (mawin_original)


Lesenswert?

Re D. schrieb:
> Das ist echt ein Skandal, den du da entdeckt hast!

Du hast dir das Video also immer noch nicht angeschaut, gell? :)

von Harald K. (kirnbichler)


Lesenswert?

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.

von Re D. (Gast)


Lesenswert?

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?

von Re D. (Gast)


Lesenswert?

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.

von Max M. (Gast)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von Jens E. (surfjenser)


Lesenswert?

Hier ein Podcast mit Chris Lattner, einem der Erfinder, von Mojo:
https://www.youtube.com/watch?v=pdJQ8iVTwj8

von Re D. (Gast)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

Re D. schrieb:
> Und schon wieder voll daneben.

Und schon wieder keine Begründung.

von Re D. (Gast)


Lesenswert?

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?

von Harald K. (kirnbichler)


Lesenswert?

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.

von Re D. (Gast)


Lesenswert?

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/

von Monk (roehrmond)


Lesenswert?

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.

von Re D. (Gast)


Lesenswert?

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.

von Gerhard O. (gerhard_)


Lesenswert?

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.

von Max M. (Gast)


Lesenswert?

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

von Re D. (Gast)


Lesenswert?

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.

von Re D. (Gast)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von Monk (roehrmond)


Lesenswert?

MaWin O. schrieb:
> Go-Programme vielleicht

Nee. Go kann C Bibliotheken aufrufen, und mit etwas Trickserei geht es 
auch umgekehrt.

: Bearbeitet durch User
von MaWin O. (mawin_original)


Lesenswert?

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.

von Monk (roehrmond)


Lesenswert?

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
von Re D. (Gast)


Lesenswert?

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?

von MaWin O. (mawin_original)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

Re D. schrieb:
> Ich weiß immer noch nicht, was deine C ABI sein soll.

Dann google doch mal.

von Re D. (Gast)


Lesenswert?

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.

von Re D. (Gast)


Lesenswert?

MaWin O. schrieb:
> Dann google doch mal.

https://de.m.wikipedia.org/wiki/Bin%C3%A4rschnittstelle

Da steht leider nichts von "C".

von MaWin O. (mawin_original)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

Re D. schrieb:
> Da steht leider nichts von "C".

Du schaffst es schon noch Google richtig zu bedienen. Da bin ich 
zuversichtlich.

von Monk (roehrmond)


Lesenswert?

Re D. schrieb:
> Da steht leider nichts von "C".

Da steht ganz allgemein "Programmiersprachen", und konkret wird C++ 
genannt (wegen einer Besonderheit).

von Re D. (Gast)


Lesenswert?

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?

von Re D. (Gast)


Lesenswert?

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?

von Re D. (Gast)


Lesenswert?

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.

von Monk (roehrmond)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von Monk (roehrmond)


Lesenswert?

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).

von Re D. (Gast)


Lesenswert?

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.

von Re D. (Gast)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von Re D. (Gast)


Lesenswert?

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.

von Gerhard O. (gerhard_)


Lesenswert?

Moin,

Das Programmieren lässt sich zum Schluß einfach auf diesen Satz 
ableiten:

                       "whatever Works!"


Gerhard

von Ein T. (ein_typ)


Lesenswert?

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/

von Harald K. (kirnbichler)


Lesenswert?

re_(nummer) argumentiert verdächtig ähnlich wie unser allseits beliebter 
"Moby".

von Ein T. (ein_typ)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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. :-)

von Stefan F. (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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?

von Ein T. (ein_typ)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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

von Monk (roehrmond)


Lesenswert?

Re D. schrieb:
> Man kann nicht alles und Detail beherrschen

Ja

von Sheeva P. (sheevaplug)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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.

von Re D. (Gast)


Lesenswert?

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.

von Re D. (Gast)


Lesenswert?

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.

von Harald K. (kirnbichler)


Lesenswert?

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.

von Falk S. (falk_s831)


Lesenswert?

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
von Ein T. (ein_typ)


Lesenswert?

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.

von Harald K. (kirnbichler)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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 :)

von Ein T. (ein_typ)


Lesenswert?

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?

von Harald K. (kirnbichler)


Lesenswert?

Ein T. schrieb:
> [X] Menschen mit Jahren oder gar Jahrzenten an Berufserfahrung?

Halte ich für unwahrscheinlich. Die haben besseres zu tun.

von Oliver S. (oliverso)


Lesenswert?

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

von Marci W. (marci_w)


Lesenswert?

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

von Ein T. (ein_typ)


Lesenswert?

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.

von Marci W. (marci_w)


Lesenswert?

Max M. schrieb:
> Bestreitet niemand. Aber Python hat gezeigt, wie schnell es sich drehen
> kann.

Hmmmm, was genau hat "Python schnell gedreht"?

ciao

Marci

von Harald K. (kirnbichler)


Lesenswert?

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.

von Re D. (Gast)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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...

von Uwe D. (monkye)


Lesenswert?

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…

von Uwe D. (monkye)


Lesenswert?

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.

von Some O. (some_one)


Lesenswert?

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.

von Re D. (Gast)


Lesenswert?

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.

von Re D. (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Sebastian W. (wangnick)


Lesenswert?

Max M. schrieb:
> Ist MoJo hier um zu bleiben? Ersetzt es C,C++, Python etc?

Ist das tatsächlich closed source?

LG, Sebastian

von MaWin O. (mawin_original)


Lesenswert?

Sebastian W. schrieb:
> Ist das tatsächlich closed source?

Ja.

von Vincent H. (vinci)


Lesenswert?

closed source -> doa

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von Oliver S. (oliverso)


Lesenswert?

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
von Stefan F. (Gast)


Lesenswert?

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

von Oliver S. (oliverso)


Lesenswert?

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

von Uwe D. (monkye)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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)

von Oliver S. (oliverso)


Lesenswert?

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

von Uwe D. (monkye)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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?

von Ein T. (ein_typ)


Lesenswert?

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ß.

von Some O. (some_one)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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
von Re D. (Gast)


Lesenswert?

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.

von MaWin O. (mawin_original)


Lesenswert?

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.

von Sebastian W. (wangnick)


Lesenswert?

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

von Ein T. (ein_typ)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Re D. (Gast)


Lesenswert?

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?

von Some O. (some_one)


Lesenswert?

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.

von Uwe D. (monkye)


Lesenswert?

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…

von MaWin O. (mawin_original)


Lesenswert?

Ein T. schrieb:
> Zumal Python gar nicht dynamisch typisiert ist.

Jetzt wirds aber wild hier. :)

von MaWin O. (mawin_original)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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 ;-)

von Sebastian W. (wangnick)


Lesenswert?

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

von MaWin O. (mawin_original)


Lesenswert?

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.

von Sebastian W. (wangnick)


Lesenswert?

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

von Ein T. (ein_typ)


Lesenswert?

MaWin O. schrieb:
> Ein T. schrieb:
>> Zumal Python gar nicht dynamisch typisiert ist.
>
> Jetzt wirds aber wild hier. :)

Kein bisschen.

von Ein T. (ein_typ)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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
von Re D. (Gast)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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...

von MaWin O. (mawin_original)


Lesenswert?

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 :)

Bitte 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
Noch kein Account? Hier anmelden.