Python schlauer ?

[Schlaues Perl]

Ich programmiere zwar Perl, aber Concurrency usw. sind bei Python von Anfang an dabei und erleichtern effiziente Programmierung gut skalierender Anwendungen doch ungemein.

Die Frage ist also, ob Perl den Schritt schafft oder doch die falsche Basis hat oder die Orientierung an möchtegern-Fancy-Features den Blick auf die Basis verschleiert oder die Berichte einfach nur Keywords rauspicken.
So wie Benzin-Autos vielleicht bald E-Autos werden, und sich per Hybrid noch ein wenig über Wasser halten werden.

Das perl und noch mehr python evolutionsmäßig in einer ganz anderen Liga spielen, als Sprachen, die an lebendige Fossilien (Silberfischchen, Krokodile, Quastenflosser,...) erinnern, sollte jedem hier klar sein.
Und C, C++, Java sind nicht gemeint, auch wenn die neuen Specs wie C99 mit parallelisierbaren for-Schleifen usw. es wohl nur irgendwann mal schaffen werden.

Aber Mini-Programmierer verstehen nicht, das man keine Lust hat, z.B. endlos dieselben Klassen unter anderen Namen umzukopieren, sondern einfach OR-Mappings oder auch GUIs usw. konfiguriert und möglichst wenig mit blossen Fingern selber programmiert, weil die Tools einem das erledigen.
Wer zweimal dasselbe programmiert, wiederholt sich, und gehört wie ein Hamster ins Rad.

[Wissard]

Schlaues Perl schrieb:
--------------------------------------------------------------------------------
> Ich programmiere zwar Perl, aber Concurrency usw. sind bei Python von
> Anfang an dabei und erleichtern effiziente Programmierung gut skalierender
> Anwendungen doch ungemein.
Was meinst du mit „Concurrency ist bei Python dabei“? Mit Nebenläufigkeiten kommt Python dank GIL nicht gerade gut zurecht.

[goldentime]

Im Thema Nebenläufigkeit kommt man im Moment leider kaum an Erlang vorbei.

[Wissard]

goldentime schrieb:
--------------------------------------------------------------------------------
> Im Thema Nebenläufigkeit kommt man im Moment leider kaum an Erlang vorbei.
Offensichtlich schon, wie man an der Verbreitung von Erlang sieht. ;)

[goldentime]

Immerhin. Die ganzen DBs z.B. CouchDB, die jetzt wie Pilze aus dem Boden schießen? Erlang. Jabberserver? Ebenfalls. Natürlich gibt es viele C und C++ basierte Frameworks.

[Schlaues Perl]

Danke für den Hinweis. Ich wusste nicht, das python so "lame" und "Retro" ist, wie linux es früher mal war und vielleicht teilweise mal war und einen zentralen Lock hat. Das ist sowas von von früher. Argl... .

Die Frage ist natürlich, wie sehr es sich auswirkt oder ob man es möglicherweise tracen und dann umgehen kann, wenn man wirklich mal seine multicore-CPU ausnutzen will.

Für Normalo-Programmierer sind Pipes und Threads und halt vermutlich einfach nur reentrante Libraries bzw. APIs eine sehr angenehme Sache. Das bezog ich auf python.

Dann hat Perl ja noch eine Chance und kann vorbeiziehen. (SCNR)

Gewisse andere hinterwäldler-Sprachen haben bis heute nicht mal Threads, soweit ich weiss. Und selbst wenn, kommen sie 10 Jahre zu spät.

Wegen GIL für die anderen noch:
Google sagt:
Global Interpreter Lock - Wikipedia, the free encyclopedia - [ Diese Seite übersetzen ]
"The GIL is a lock that is used to protect all the critical sections in Python. Hence, even if you have multiple CPUs, only one thread may be doing ...

[Yoschi]

> Jabberserver
Gibst auch Alternativen zB Prosody geschrieben in Lua.

[Scalierer]

Scala ftw

[Theoret]

Scala will ich aber nicht dazu benutzen. Vor allem weil man dann von Oracle abhängig ist, die in die VM nicht wirklich Elan reinstecken.

Natürlich gibt es noch andere VMs, aber deren genaue Kompatibillität ist theoretisch.

[panzi]

Wenn man schon keine echten Threads hat (wegen GIL) dann kann man auch gleich ganz auf Threads, Locks etc. verzichten und lieber asynchron und non-blocking programmieren, so weit es geht (siehe Twisted).

[Schlaues Perl]

GILs können unterschiedlich ausgestattet sein.
Manche blockieren die komplette virtuelle Maschine.
Andere blockieren hingegen nur manche Threads der virtuellen Maschine. Z.b. wenn man mit printf oder sowas etwas ausgeben will.
Die anderen "Threads" könnten aber weiter laufen. Und sowas ist schon effizienter.
Wichtig heutzutage ist, das man nicht mehr seriell programmiert sondern OO-mäßig mit Workern die Jobs bekommen und abarbeiten und das möglich skalierbar und wenns geht auch gleichzeitig auf verschiedenen CPU-Threads bzw. Cores.

Auf einem Single-Core-Atom merkt man dann hoffentlich kaum etwas für den (laut single-threadern-Assembler-Programmierer-Fans) angeblich so vielen Verwaltungs-"Overhead". Auf einem Dual-Atom läuft es dann aber vielleicht doppelt so schnell oder über-linear, wenn Teile der Probleme plötzlich in die Caches passen.

Die Intel-Konferenzen wurde früher immer herumgejammert, wie man die zillionen single-thread-Progger dazu kriegt, MultiThreaded und MultiCore-mäßig zu programmieren.
OO bietet das implizit. Anfänger lassen sich halt von Firlefanz wie mehrfachem Erben usw. beeindrucken und peilen in ihrer micro-ben-mäßigen Einfaltslosigkeit die Eleganz von Infrastrukturen wie J2EE niemals.